노드에 작업이 주입되었지만 블록 체인에 추가되지 않음 | 지갑 카운터 오류
1 대답
- 투표
-
- 2020-01-02
TLDR : 노드에 삽입 한 첫 번째 작업은 유효하지만 수수료가 너무 낮기 때문에 다른 노드/베이커가 삽입하지 않습니다. 그런 다음mempool에 갇혀 사용하려는 다음 유효한 카운터가 이미 너무 낮은 수수료 작업에 의해 사용 중이기 때문에 위조하려는 다음 작업을 무효화합니다. 노드를 다시 시작하거나 60 개의 블록이 지나갈 때까지 기다렸다가 상황을 풀 수 있습니다.
<시간>내 생각에 당신이 주입 한 첫 번째 작업이 다른 동료에 의해 유효하지 않은 것으로 간주된다는 것입니다. 말씀하신대로 여러 가지 이유로 거부 될 수 있습니다 (가장 일반적인 경우는 수수료가 충분하지 않음).
그래서 프로토콜과 관련하여 유효하고 따라서mempool에서 유효한 작업을 위조했습니다. 일부 베이커가 수수료가 0 인 작업을 수락하고 포함 할 수 있으므로 노드가 작업 주입을 수락했습니다. 그러나 기본적으로는 그렇지 않습니다. 노드에 주입 한 작업은 제빵사가 블록에 포함 할 때까지 기다리는mempool에 있습니다.이제 기술적 인 부분이 있습니다. 노드에 작업을 위조하도록 요청하면 클라이언트 (또는 사용중인 API)가 노드에서 계정에 연결된 카운터를 요청합니다 (참고 : 카운터는 재생 공격을 방지하기 위해 여기에 있음). 이 정보를 얻기 위해 노드는 체인의 현재 상태 (즉,수신 된 마지막 블록의 적용 결과 상태)를 사용하여 데이터를 쿼리하고 예를 들어
를 반환합니다. 1000
. 단조하려는 작업이 유효하려면 카운터가1001
이어야합니다. 그렇지 않은 경우 노드가 유효성을 검사하려고 할 때과거의 카운터
또는미래의 카운터
오류가 발생합니다.귀하의 경우 카운터
128324
를 사용하여 너무 낮은 수수료 작업을 삽입했습니다. 귀하의 노드는 귀하가 무엇을하고 있는지 (예 : 저비용 제빵사에게 주입하려고 시도) 알고 있다고 간주하므로 수수료를 확인하지 않습니다. 네트워크에서 실행되는 저렴한 제빵사가 없으면 작업이 포함되지 않고60
블록 (바빌론 넷에서 최소 20 분)에 대한mempool에 갇히게됩니다. 이 60 개 블록 이후에는 작업이 너무 오래된 것으로 간주되어mempool에서 제거됩니다. 이것이 얼마 후 상황이 풀린 이유입니다.이제이 유효하지 않은 작업이mempool에 갇혀있는 동안 클라이언트를 사용하여 위조 한 다음 작업도 노드에서 카운터를 요청하며 마지막 작업이 포함되지 않았으므로 이전 카운터
128324
이전 트랜잭션과 충돌하는 경우 다시 사용됩니다. 이런 일이 발생하면mempool은 작업을 하나씩 검증하려고 시도하기 때문에 만족하지 않습니다. 첫 번째 작업이 유효하므로 (포함되지 않더라도) 첫 번째 작업이 적용된 중간 상태 인 내부 상태 에 적용되어 다음 예상 카운터가 하나. 다음 번에 동일한 계정에 대한 작업이 수신 될 때mempool은 카운터가128325
로 증가 할 것으로 예상합니다. 그렇지 않은 경우과거의 카운터
오류와 함께 거부됩니다. 카운터를 수동으로 늘리려 고하면향후 카운터
가 표시 될 수 있습니다.이 상황에서 벗어나는 방법 :
- 60 개의 블록이 지나갈 때까지 기다리면 거래가 너무 오래되어 폐기됩니다.
- 노드를 제어 할 수 있으면 다시 시작할 수 있습니다.mempool은 노드가 중지되면 지워집니다.
- 다른 노드를 사용하여 거래를 위조하고 삽입 할 수 있습니다. 하나는mempool에 잘못된 작업이 멈춰 있지 않습니다.
다음 셸 릴리스에서는mempool에서 특정 작업을 제거하는 데 사용할 관리자 RPC를 포함하는 것을 목표로합니다.
추신 RPC
를 사용하여mempool에있는 작업을 확인할 수 있습니다./chains/main/mempool/pending_operations
TLDR: the first operation you injected in your node is valid but will be never be injected by other nodes/bakers because it has too low fees. It is then stuck in the mempool and make the the next operations you're trying to forge invalid because the next valid counter you want to use is already being taken by the too low fee operation. You can restart your node or wait for 60 blocks to pass to unlock the situation.
What I believe happens here is that the first operation you injected is considered invalid by your other peers. As you said, it can be rejected for multiple reasons (not enough fees being the most common case).
So, you forged an operation which is valid regarding the protocol and therefore valid in the mempool. Your node accepted injecting the operation because some bakers might be accepting and including 0 fees operations. However, by default, this is not the case. The operation you injected in the node is thus living in the mempool waiting for a baker to include it in a block.
So now comes the technical part. When you request the node to forge an operation for you, the client (or the API you're using) will request from the node the counter associated to your account (side note: the counter is here to prevent replay attacks). To grab this information, the node will query the data using the current state of the chain (i.e. the state that results from the application of the last block received) and will return, for example,
1000
. For the operation you're forging to be valid, its counter must then be1001
. If this is not the case, it will give you acounter in the past
orcounter in the future
error when the node is trying to validate it.In your case, you injected a too low fee operation with a counter
128324
. Your node considers that you know what you're doing (e.g. trying to get a low-fee baker to inject it) and thus does not check for the fees. If there are no low-fee baker running in the network, your operation will never be included and stuck in the mempool for60
blocks (20min minimum in babylonnet). After those 60 blocks, the operation will considered too old and purged from the mempool. This is why, after some times, the situation was unlocked.Now, while this invalid operation is stuck in the mempool, the next operation you forge using the client will also request the counter from the node and as your last operation was not included, the previous counter
128324
will be used again which collides with the previous transaction. When this happens, the mempool is not happy because it will try to validate the operations one after the other. As your first operation is valid (even if it will never be included), it will be applied on its internal state which is an intermediate state where your first operation was applied thus making the next expected counter increased by one. The next time an operation is received (for the same account) the mempool will expect the counter to be increased to128325
. If that's not the case, then it will reject it with acounter in the past
error. If you try to manually increase the counter, you might getcounter in the future
.How to get out of this situation:
- you may wait for 60 blocks to pass by and then your transaction will be discarded for being too old;
- you can restart your node if you have control over it. The mempool is erased when the node stops;
- you can forge and inject your transaction using another node. One, which will not have the invalid operation stuck in its mempool.
In the next shell release, we aim to include an admin RPC that will be used to remove a specific operation from the mempool.
P.S. You may check which operations live in the mempool using the RPC
/chains/main/mempool/pending_operations
-
그런 다음 동일한 블록에서 여러 트랜잭션을 어떻게 보내겠습니까?이전 작업이 아직 확인되지 않은 한,이 불일치로 인해 새로운 작업을 브로드 캐스트 할 수 없다는 뜻이 아닙니까?How would you then send multiple transactions in the same block? Doesn't that mean that as long as the old operation is not yet confirmed, we can't broadcast any new operation because of this mismatch there?
- 0
- 2020-05-09
- CherryDT
내 자신의babbylon 노드를 사용하고 이전에tezos 수도꼭지에서 지갑을 추가하고tezos-client를 사용하여 생성 된 지갑으로 동전을 보냈습니다.
eztz.js를 통해 보내기
이제eztz.js lib를 사용하여 생성 된 지갑에서 다른 지갑으로tezos를 보내려고합니다. 다음 코드를 사용하세요.
처음 실행할 때-노드가 내 작업을 주입하고 트랜잭션 주소를 반환하지만이 전송은 블록 체인에 추가되지 않았고 잔액이 변경되지 않았습니다. 최초 작업 로그 :
두 번째 전송을 시도 할 때-카운터 오류 발생 :
두 번째 시간 로그 :
수동으로 카운터를 128326으로 설정하면
counter_in_the_future
오류가 발생합니다.반 시간이 지나도 카운터 오류가 사라졌지 만 여전히 코인을 보내려고하면-작업이 블록 체인에 포함되지 않고 카운터 오류가 다시 발생합니다.
tezos-client를 통해 보내기
생성 된 개인 키를test_w2로 가져와tezos-client로 코인을 보내려고합니다.
처음으로 동일한 카운터 오류가 발생했습니다.
하지만 30 분 후에 효과가있었습니다.
따라서 지갑 생성이나 테 조스 노드가 아닌 오류,eztz.js 클라이언트 또는 전달 된 값에서만 오류가 발생할 수 있습니다. 수수료/가스 한도/금액을 잘못 넘겼을까요?이 문제를 어떻게 해결할 수 있습니까?
참고. 사실 나는 분기 된 Tz.Net 라이브러리 (c #)를 사용하지만eztz.js와 동일한 워크 플로우를 가지고 있으며 동일한 오류가 발생합니다.