단일 노드를 사용하는 동안 이중 베이킹 / 보증이 가능합니까?

Question

단일 노드를 사용하는 동안 이중 베이킹 / 보증이 가능합니까?

- 3
- 131 2019-04-16
테 조스 노드에는 이미 주입 된 블록이 다시 주입되는 것을 거부하는 보호 기능이 있습니까?

고발자 모듈을 테스트하려고하는데 이중 베이킹을 할 수 없습니다.

내 앱이 이미 해당 블록을 구운 경우 두 번째 주입을 시도하면이 문제가 발생합니다.
<인용구>
[{ "kind": "temporary","id": "failure","msg": "피트니스가 너무 낮음"}]

동일 블록의 이중 주입을 거부하는 노드에 이미 어떤 종류의 보호가 있습니까?

수정 :

이제 tezos-node 바이너리를 사용하는 동안 이중 베이킹이 불가능한 것 같습니다.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": "Fitnesstoo low"}]를 제공합니다.
  
  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

여기에 몇 가지 문제가 있습니다.

이중 베이킹/보증이란 무엇입니까?

배가 페널티는 주입과 거의 관련이 없음을 이해하는 것이 중요합니다. 범죄는 동일한 수준에서 서로 다른 해시를 사용하여 서로 다른 두 블록 또는 보증을 서명 하는 것입니다. 주사는 범죄를 발견하는 한 가지 방법 일뿐입니다.

해시로 식별되는 단일 블록 또는 보증을 원하는 수의 노드에 여러 번 안전하게 삽입 할 수 있습니다.

반면에,증거 작업에만 포함 된,전혀 주입되지 않은 블록 서명 또는 승인에 대해서는 처벌을받을 수 있습니다.

경고입니다. 이중 주입을 방지하는 메커니즘에 의존해서는 안됩니다.baker,endorser,signer 및 Ledger 앱과 같은 수준 높은 워터 마크를 사용하여 이중 서명을 방지해야합니다. 이중 서명은 범죄입니다. 이중 주사를 막으려는 것은 잡히지 않으려는 것입니다.

이제 두 번 굽는 방법을 알아 보겠습니다 ...

피트니스가 너무 낮음

먼저,/injection/block RPC는 적합하지 않은 블록을 거부합니다. 적합하지 않은 블록을 강제로 삽입하려면 문서

결정적 서명

결정적 서명 체계 (tz1/ed25519와 같지만 다른 서명은 아님)를 사용하여 정확히 동일한 블록 또는 보증 데이터에 두 번 서명하면 동일한 서명을 받게됩니다. 그러면 결과 블록/작업 해시는 동일합니다. 매우 동일한 블록/작업이므로 두 배가되지 않습니다.

따라서tz1로 이중 베이킹을 발생 시키려면 두 블록 사이의 블록 데이터를 수정해야합니다. 타임 스탬프 또는 작업을 변경합니다.

예

다음은 샌드 박스에서 이중 베이킹을 수행하는 비교적 쉬운 방법입니다.

 # 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을 사용하더라도).
노드는 블록의 유효성을 검사하고 고소자는 블록을 선택합니다.
그러나 우리는 보증을 주입했지만 아무것도 구워지지 않았기 때문에 노드는 블록을 무시합니다. 이렇게하면 헤드가 이전 수준에 있기 때문에 굽기를 쉽게 반복 할 수 있습니다.
마지막으로 "blocks"하이 워터 마크 파일을 제거하여 제빵사의 이중 베이킹 보호를 파괴합니다.

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.

출처
Tom

답변 해 주셔서 감사합니다!

Thanks for your answer!
- 0
- 2019-04-18
- RoMarQ
톰,왜 고소인이 이중 제빵의 50 %를 감지하지 못하는지 아십니까? 제로 넷에서 가끔 제 이중 제빵이 감지되지 않는 경우가 있습니다.내 고발자는 감지하지 못하고 다른 사람은 감지합니다. 이것은 내 자신의 고발자에 의해서만 발견되었습니다 : 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
@Seb Mondet이 이미 대답했습니다. "일반적으로 네트워크는 체력을"개선 "하는 블록을 전파합니다. 따라서 구워진 블록이 승인되지 않은 경우 고소자는이를보고 비난을 주입하지 않을 것입니다." "전반적인 비난은 네트워크 속도를 늦추거나 손상시키지 않는 우발적 인 이중 굽기뿐만 아니라 정말 성가신 행위자에게 처벌을 내 리도록 설계되었습니다." "(다소 불운 한 상황에서 우발적 인 이중 베이킹이 당연히 비난받을 수 있습니다.)"

@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