シングルノードを使用しながら、ダブルベーキング/承認は可能ですか？

Question

シングルノードを使用しながら、ダブルベーキング/承認は可能ですか？

- 3
- 131 2019-04-16
tezosノードには、すでに注入されたブロックが再度注入されるのを拒否するような保護がありますか?

accuserモジュールをテストしようとしていますが、ダブルベイクを実行できません.

アプリがすでにそのブロックをベイクしている場合、2回目に注入しようとすると、これが表示されます.

[{"kind": "temporary"、 "id": "failure"、 "msg": "Fitnesstoo low"}]

同じブロックの二重注入を拒否するノードの保護はすでにありますか?

編集:

tezos-node バイナリを使用している間は、ダブルベイクすることは不可能になっているようです.2つの異なるノードでダブルベイクを試みたところ、2番目に挿入されるたびに、[{"kind":"temporary","id":"failure","msg":"Fitness too low"}].

Does tezos node have any kind of protection that rejects a block that has already been injected from being injected again?

I'm trying to test my accuser module, but can't make any double baking.

If my app has already baked that block, when I try to inject it a second time I get this.

[{"kind":"temporary","id":"failure","msg":"Fitness too low"}]

Is there any kind of protection on the nodes already that rejects double injections of the same block?

EDIT:

Looks like that is now impossible to double bake while using tezos-node binary. Just tried to double bake with 2 different nodes and every injection that comes in second place gives a [{"kind":"temporary","id":"failure","msg":"Fitness too low"}].

node baker accuser double-baking

- tezos-nodeバイナリを使用している間は、ダブルベイクすることは不可能になっているようです.2つの異なるノードでダブルベイクを試みたところ、2番目に来るすべての注入で、[{"kind": "temporary"、 "id": "failure"、 "msg": "Fitnesstoolow"}]が得られます.
  
  Looks like that is now impossible to double bake while using tezos-node binary. Just tried to double bake with 2 different nodes and every injection that comes in second place gives a [{"kind":"temporary","id":"failure","msg":"Fitness too low"}].
  - 0
  - 2019-04-17
  - RoMarQ

1 回答

投票

Tom · Accepted Answer · 2019-04-17

3

2019-04-17

ここにはいくつかの問題があります.

ダブルベーキング/承認とは何ですか?

倍増ペナルティは注射とはほとんど関係がないことを理解することが重要です.犯罪は、同じレベルで、ハッシュが異なる2つの異なるブロックまたは承認に署名することです.注射は、犯罪を発見するための1つの方法にすぎません.

ハッシュで識別される単一のブロックまたは承認を、任意の数のノードに何度でも安全に挿入できます.

一方、証拠操作にのみ含まれている、まったく注入されなかったブロックまたは承認の署名に対して罰せられる可能性があります.

つまり、警告です.二重注入を防ぐメカニズムに頼るべきではありません.パン屋、承認者、署名者、元帳アプリなどのレベルの高い透かしを使用して、二重署名を防ぐ必要があります.二重署名は犯罪です.二重注射を防ごうとすることは、引っ掛からないようにすることです.

それでは、ダブルベイクする方法を見てみましょう...

フィットネスが低すぎる

まず、/injection/blockRPCは不適合なブロックを拒否します.不適合ブロックの注入を強制するには、force=trueクエリパラメーターを指定できます. -injection-block "rel="nofollownoreferrer ">ドキュメント.

決定論的署名

決定論的署名スキーム(tz1/ed25519など、他のスキームではない)を使用して、まったく同じブロックまたは承認データに2回署名すると、同じ署名が取得されます.その場合、結果のブロック/操作ハッシュは同じになります.まったく同じブロック/操作であるため、倍増はありません.

したがって、tz1でダブルベイクを発生させるには、2つのブロック間のブロックデータを変更する必要があります.タイムスタンプまたは操作を変更します.

例

サンドボックスでダブルベイクする比較的簡単な方法の1つは次のとおりです.

 # DANGER, DOUBLE BAKING, FOR SANDBOX
tezos-client rpc get /chains/main/mempool/pending_operations | jq '.applied = []' > /tmp/empty_mempool.json
tezos-client endorse for bootstrap1
tezos-client bake for bootstrap1 --mempool /tmp/empty_mempool.json
# fix the path, for your TMP SANDBOX (!) client
# DO NOT delete your real "blocks" file!
rm /tmp/tezos-tmp-client.XXXXXXXX/blocks
tezos-client bake for bootstrap1 --mempool /tmp/empty_mempool.json

これは次の理由で機能します:

bake forはデフォルトで現在のタイムスタンプを使用するため、ベイクの合間に少し待つと、ブロックデータのタイムスタンプが異なり、結果としてブロックが異なります(tz1の場合でも).
ノードがブロックを検証し、告発者がブロックを取得します.
ただし、承認を挿入したものの、何も指定せずにベイク処理したため、ノードはブロックを無視します.これにより、ヘッドが前のレベルのままになるため、ベイクを簡単に繰り返すことができます.
最後に、「ブロック」の最高水準点ファイルを削除することで、パン屋の二重焼き保護を覆します.

There are a few issues here.

What is double baking/endorsement?

It is important to understand that the doubling penalty has little to do with injection. The crime is signing two different blocks or endorsements, with different hashes, at the same level. Injection is just one way for your crime to be discovered.

You can safely inject a single block or endorsement, identified by its hash, any number of times into any number of nodes.

On the other hand, you could be punished for signatures of blocks or endorsements which were never injected at all, only included in the evidence operation.

So, a warning. You should not rely on mechanisms which prevent double injection. You should prevent double signing, using level high watermarks, like the baker, endorser, signer, and Ledger app. Double signing is the crime. Trying to prevent double injection is trying not to get caught.

Now, let's see how to double bake...

Fitness too low

First, the /injection/block RPC rejects unfit blocks. To force injection of unfit blocks, you can supply the force=true query parameter, mentioned in the docs.

Deterministic signatures

With a deterministic signature scheme (like tz1/ed25519, but not the others), if you sign the exact same block or endorsement data twice, you're going to get the same signature. Then the resulting block/op hash will be the same. Since it is the very same block/op, there is no doubling.

So, to cause double baking with tz1, you need to modify the block data between the two blocks, e.g. change the timestamp or operations.

Example

Here is one relatively easy way to double bake in a sandbox:

# DANGER, DOUBLE BAKING, FOR SANDBOX
tezos-client rpc get /chains/main/mempool/pending_operations | jq '.applied = []' > /tmp/empty_mempool.json
tezos-client endorse for bootstrap1
tezos-client bake for bootstrap1 --mempool /tmp/empty_mempool.json
# fix the path, for your TMP SANDBOX (!) client
# DO NOT delete your real "blocks" file!
rm /tmp/tezos-tmp-client.XXXXXXXX/blocks
tezos-client bake for bootstrap1 --mempool /tmp/empty_mempool.json

This works because:

bake for uses the current timestamp by default, so if we wait a bit between bakes, the timestamp in the block data will be different, resulting in different blocks (even with tz1.)
The node validates the block, and the accuser picks up on it.
However, because we injected an endorsement but baked with none, the node then ignores the block. This makes it easy to repeat the bake, because the head will still be at the previous level.
Finally, we subvert the baker's double bake protection, by removing the "blocks" high watermark file.

ご回答有難うございます！

Thanks for your answer!
- 0
- 2019-04-18
- RoMarQ
トム、告発者がダブルベーキングの50％のように検出しない理由を知っていますか、zeronetで時々私のダブルベーキングが検出されないことがあります.たとえば、私の告発者が私のダブルベーキングを検出できる場合もあれば、検出できない場合もあります.私の告発者は検出せず、他の人は検出します. これは私自身の告発者によってのみ検出されました:https://imgur.com/OTCv0uj これは、ベーキングアプリ用の告発モジュールを作成していて、すべてが正しく機能していることを確認したいためです. これは、すべての有効なブロックを適切に追跡しない「/monitor/valid_blocks」の問題になる可能性がありますか?

Tom, do you know why the accusers don't detect like 50% of double bakings, on zeronet sometimes my double bakings aren't detected, for example, sometimes my accuser is able to detect my double baking while others don't and sometimes my accuser doesn't detect and others do. This one was only detected by my own accuser: https://imgur.com/OTCv0uj This is because I'm making an accuser module for my baking app and I want to make sure everything is working correctly. Can that be a problem with "/monitor/valid_blocks" that doesn't track every valid block as it should?
- 0
- 2019-04-22
- RoMarQ
@SebMondetはすでに回答しています. 「一般に、ネットワークは適応度を「改善」するブロックを伝播します.したがって、ベイクされたブロックが承認されていない場合、告発者はそれを見て告発を注入する可能性は低くなります.」「全体的な告発は、ネットワークの速度を低下させたり傷つけたりしない偶発的なダブルベーキングだけでなく、本当に迷惑なアクターにペナルティを科すように設計されています.」「(もちろん、やや不運な状況では、偶発的なダブルベーキングが非難されることもあります)」

@Seb Mondet already answered. "In general the network will propagate blocks that "improve" the fitness. So if your baked block has not been endorsed, accusers are not likely to see it and inject the accusation." "Overall the accusations are designed to penalize really annoying actors, not just accidental double-bakings that don't slow-down or hurt the network." "(it can still happen that in somewhat unlucky circumstances, an accidental double-baking gets accused of course)"
- 0
- 2019-04-22
- RoMarQ