Hyperledger fabric has its consensus that contains

  • Transactions endorsement
  • Transactions ordering
  • Transactions committed to a block

I wonder if there is an Ethereum consensus or fork that would have this ordering feature - that might help around the attack vector that is Transaction-ordering attack


Transaction order is a primary concern for both networks. It's vital because consensus about state is not possible without first agreeing on an order of events.

Hyperledger Fabric employs an Ordering Service. Ethereum employs a decentralized Proof-of-Work mining process with plans to transition to a more computationally efficient process.

As a grossly over-simplified summary, Ethereum miners compete for the privilege of ordering transactions much like HLF's Ordering Service. They win the privilege by "solving" a block and the privilege lasts for one block. "Solving" a block is somewhat like a winning a lottery.

In both systems, a block is a well-ordered set of transactions.

A transaction ordering attack is when someone has knowledge of a pending transaction before it's mined and uses that information to their advantage. For example, this naive function is not safe from it:

function openLockAndWithdraw(bytes32 naivePassword) public {
  require(naivePassword == storedPassword);

It's not safe, because the input naivePassword will be widely known before the transaction is mined. Someone may try to "race" by submitting a similar transaction using their knowledge of the password and a higher gasPrice perchance to be lucky enough to be mined first and get the prize.

A similar race condition is possible in HLF. Validators will know the inputs first, then the Ordering Service. If any of those operators is dishonest then they can indeed use the knowledge acquired. That is to say, HLF's Ordering Service doesn't provide protection from transaction order attacks. It merely reduces the possible opportunists who can take advantage of it to the Validators and Ordering Service. Since HLF is a permissioned system it's easy to lose sight of the possibility of a dishonest participant. Patterns that work in Ethereum's "everybody knows" setting will also work in HLF's "a few trusted Validators and Orderers know" setting.

Developers can avoid this problem on either platform by being mindful of race conditions and restricting functions so they only work as intended in all cases. In the simple example above, the problem would be resolved by ensuring the transfer only goes to the intended recipient (regardless of who sent the password).

Hope it helps.

| improve this answer | |
  • Not related but any idea about this one : ethereum.stackexchange.com/q/82594 – user2284570 Apr 18 at 16:56
  • Too much ambiguity relying on a partial description of the contract instead of the actual code. Goodvibration has good comments even though the OP doesn't seem to agree. – Rob Hitchens Apr 18 at 19:18
  • Sorry I was meaning answers to the question which don’t need an understanding of the underlying problem. For the remaining, you should understand that I don’t want to add more competitors. – user2284570 Apr 18 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.