[SNatives] Implement mainline Ethereum precompiles

[silasdavis]

Ethereum ships with a number of 'precompile' contracts - implemented in the native language of the VM our equivalent is SNatives.

We should aim to implement all the same precompiles that mainline Ethereum clients do, which are listed below along with their addresses.

@madiazp has expressed an interest in work on implementing some of these, which we would very gratefully accept! See #1224 for some background motivation for this ticket.

It might make sense to split this ticket between the first four basic precompiles which will be much more straightforward to implement than the newer elliptic curve primitives.

The explicit precompile addresses can be configured here: https://github.com/hyperledger/burrow/blob/develop/execution/evm/native.go#L50-L52

• 0x1: Recovery of ECDSA signature
• 0x2: Hash function SHA256
• 0x3: Hash function RIPEMD160
• 0x4: Identity (i.e. return whatever input is)
• 0x5: Modular exponentiation (EIP 198)
• 0x6: Addition on elliptic curve alt_bn128 (EIP 196)
• 0x7: Scalar multiplication on elliptic curve alt_bn128 (EIP 196)
• 0x8: Checking a pairing equation on curve alt_bn128 (EIP 197)

List above adapted from: https://ethereum.stackexchange.com/questions/15479/list-of-pre-compiled-contracts

[madiazp]

It seems that you have implemented the SHA256, RIPEMD160 and the Identity functions. The ones that are no implemented are the 1st and the 5 last ones (the 5,6,7,8 and the 9th, the blake2F that is part of the Istanbul hard fork).

For my project I need the 5,6,7 so I'll start to work with the 5th.

[silasdavis]

I should have originally remembered we do of course have 2, 3, 4 already implemented.

There was some prior work done for 0x1 - #777. Unfortunately that could not get merged back at the time - we didn't want the C dependency. @smblucker you got in touch recently, I wonder if you'd like to revive that change - ideally against btcsuite. Would be glad to accept.

@seanyoung has completed to refactoring work I was keen to see get in before this and I will review and merge shortly: #1242. So @madiazp if you could base your work on 0x5 then that'd be great.

[silasdavis]

I am copying this in from chat.hyperledger.org for visibility from @madiazp:

burrow has implemented the byzantium/constantinople hard fork? what will happen with the istambul one?

Yes Burrow should have all the opcodes from Constantinople.

Our approaches to new opcodes that Ethereum has to handle as a hard fork at a particular height is to just add the opcodes to the latest Burrow. Unlike go-ethereum Burrow has no conditional logic to change its operation on certain threshold heights. This is something we could add if there was demand but it adds complexity and implementing the latest standard without conditional logic or further indirection helps us stay a bit more agile and lets us make some hay out of being EVM but not protocol compatible with mainnet. Also since we have no single chain to reference we would need configuration for each of the upgrade thresholds.

Our approach to chain upgrades is via our dump/restore functionality (see: http://hyperledger.github.io/burrow/#/tutorials/7-dump-restore). I think we may want to consider recasting this as Burrow 'forking', right now it is discussed mostly in the language of 'backing up a chain' but really what it does is allows you to import state into a new chain and via the genesis AppHash to point a block on a previous chain. In doing so you can deal with almost all breaking changes (between Burrow versions and network changes) without the cost of maintaining legacy processing code in successive versions of Burrow. All of the previous blocks can be preserved in perpetuity as evidence and the AppHash to the old chain in effect gives you a chain of chains. At some point I'd like to provide the ability to fork directly from a smart contract, which combined with governance primitives I think could offer a nice model for upgrades.

[madiazp]

Ok, So the contracts that will be included are the Istambul ones.

The https://github.com/hyperledger/burrow/pull/1242/files also applies on the natives? the description struct and so on didn't seems to be applied to them.

[silasdavis]

Ok, So the contracts that will be included are the Istambul ones.
Yep that's what we should aim for generally.

[gregdhill]

9th precompile: ethereum/EIPs#152

[vgrabovski-lacero-platform]

Hello community. Any updates on first precompile ?

[vgrabovski-lacero-platform]

recovery of ecdsa signature: #1415