If a private smart contract deployed on Pente happens to have a method that emits events only (and does not modify contract storage), then the contract address shows up in getUpdatedAccounts(), but has no changes (that is, none of the 4 core account fields address, nonce, balance, code has changed). This means that Pente computes the exact same state hash as both an input state and an output state of the transition, which is not allowed.
Simple contract that reproduces the problem when calling set():
The symptom is that Paladin finds a conflicting "new state confirmed" event for a state that was already confirmed previously:
[2024-10-01T13:15:33.240-04:00] ERROR PD010121: Pending confirmation for transaction 9592b2a4-34fd-4328-a573-d9f86f61505b found when attempting to confirm from transaction 810535d4-5447-4328-88eb-83c0878ca32b (attempt=1) eventstream=b18f254e-cf52-4387-9c50-294c28e441c7 pid=80759
Therefore it gets in a retry loop while trying to make sense of the transaction, and cannot move forward.
If a private smart contract deployed on Pente happens to have a method that emits events only (and does not modify contract storage), then the contract address shows up in
getUpdatedAccounts()
, but has no changes (that is, none of the 4 core account fieldsaddress, nonce, balance, code
has changed). This means that Pente computes the exact same state hash as both an input state and an output state of the transition, which is not allowed.Simple contract that reproduces the problem when calling
set()
:The symptom is that Paladin finds a conflicting "new state confirmed" event for a state that was already confirmed previously:
Therefore it gets in a retry loop while trying to make sense of the transaction, and cannot move forward.