Merkelize Blocks

[arrivets]

Today, the block hash is computed from the JSON encoding of its Body.

We could do something smarter using Merkle trees. This would be helpful because we could then create Merkle proofs that things belong to the Block (transactions, receipts, state-hash, peer...etc).

Use something simple enough that it can be implemented in Solidity as well (Babble light-client smart-contract)

[alphaqiu]

I don't think Babble has validated its validity for the transaction, even if you use the Merkel tree, you can't guarantee the double spending problem.

[arrivets]

I don't think Babble has validated its validity for the transaction, even if you use the Merkel tree, you can't guarantee the double spending problem.

What do you mean by Babble has validated the transaction? If I understand correctly you are referring to the validity of the transaction from the application's perspective (ex evm-lite).

This issue is concerned with the internals of a Babble block. Basically, how to create a hash of the Block in a way that we can later prove that something actually belonged to the block (like a transaction, a receipt, or a peer). So we are not concerned with the validity of transactions with respect to the application.

[alphaqiu]

I don't think Babble has validated its validity for the transaction, even if you use the Merkel tree, you can't guarantee the double spending problem.

What do you mean by Babble has validated the transaction? If I understand correctly you are referring to the validity of the transaction from the application's perspective (ex evm-lite).

This issue is concerned with the internals of a Babble block. Basically, how to create a hash of the Block in a way that we can later prove that something actually belonged to the block (like a transaction, a receipt, or a peer). So we are not concerned with the validity of transactions with respect to the application.

Sorry, you understand that it is right. I am here to talk about the consensus verification transaction. But my idea is this, if the consensus does not verify the validity of the transaction, it will be double-spend attack. Because evm-lite does not synchronize transaction lists between nodes, and the nonce value of a single account will only increase on one node. If an account initiates a transaction at the same time on multiple nodes, or captures a transaction datagram for one account, and replays on other nodes, the hashgraph mechanism may appear to cause transactions of the same nonce value to be packaged into the block. Babble is a versatile design, but if there is a transfer of funds, is there a risk?

[arrivets]

The EVM enforces transactions to have incrementing nonces. If you try to apply a transaction with a nonce less-or-equal to the sending account's current nonce, the transaction will be rejected. This is what prevents double-spend attacks.

But I think I understand what you are saying. In the scenarios you described, it is indeed possible for a Babble block to contain two transactions with the same nonce or, more generally, to contain transactions with incorrect nonces. These transactions will be refused at the application-layer by evm-lite. So there is no risk at the application layer, but the Babble (hashgraph + blockchain) may contain "rubbish" transactions, which could be a vector of denial of service.

Other projects, like Ethereum or Tendermint, expose a CheckTransaction endpoint that filters-out invalid transactions before they get added to a block by the block proposer. In our case, the check would have to be done before inserting a Hashgraph Event. This deserves a separate issue as it is not really related to this merklization thing.

That being said, the question has be raised several times so I will create a separate issue about adding a e CheckTransaction method in the AppProxy interface.