ethereumproject
ECIP-1046: Precompiled contract for verification of Merkle Inclusion Proofs
One issue that has been brought up is that this is solely compatible with BTC, but we may want to support other Merkle structures too. One idea is to add an extra argument to the contract call indicating the method with which the Merkle tree was built and having 0 indicate the BTC structure, 1 indicating the Merkle-Patricia try of ETC, and so on. However, perhaps this is overkill. I was wondering what the community thinks about this concern.
~Solidity supports function overloading so couldn't you have the same function accept different byte datatypes? byte32, byte64, etc. So byte32 could accommodate Bitcoin and other types could accommodate chains that allow for longer hashes.~
~If this works then:~ ~- We'd avoid mistakes where people try to use the wrong function/don't properly declare which blockchain they're validating from.~ ~- We get something more generic documentation-wise. For example the ECIP, on top of supporting BTC/BCH likely also supports LTC/DOGE/VTC.~
~Or is the structure of the Bitcoin vs. Ethereum Merkle trees completely different? I'm admittedly not too knowledgeable on this.~
@pyskell which chain do you have in mind with Merkle Tree hashes over 256 bits? AFAIK all the coins you mentioned use double SHA256, and Ethereum uses Keccak-256, which all produce exactly 256-bit, or byte32 outputs.
I think @pyskell confused 32 bytes (= 256 bits) with 32 bits.
PS it would be nice to use bits in the ECIP, for better readability.
I would again like to point out that this ECIP even though pretty concrete is incomplete without a gas cost. I'd really appreciate some pointers for this.
Heres my copy of gas prices sheet, the precompiles are set relative to their compute time vs internal operations.
https://docs.google.com/spreadsheets/d/1552qFFWES858IXHlW_wtRINTowMIEkLEf2fZyK_xiEo/edit?usp=drivesdk
revised version https://docs.google.com/spreadsheets/d/1n6mRqkBz3iWcOlRem_mO09GtSKEKrAsfO7Frgx18pNU/edit#gid=0
@realcodywburns thanks for the gas prices sheet, I'm not really sure how to utilise it though as SHA256 is not a primitive operation and it's not included there.
I've had difficulty finding any resources on how to appropriately price precompiled contracts, so help would be much appreciated here. Is there a rationale behind pricing? Some invariant I should make sure not to violate?
What I'm at currently thinking is that we're doing 2 sha256 operations per sibling, so we should charge less than 2 * siblings.length * sha256Cost? Maybe some base gas as well?
I would like to reiterate that we'd like to also provide a meaningful metric about how much the implementation of this ECIP will improve the gas-performance of NIPoPoW verification, even though this may not need to be part of the ECIP itself. This is something we're working on currently.
There are two kinds of costs here, one being the computation time for the SHA2 calls, the other is the cost of accessing the memory elements. The elements in memory are assumed to already be contiguous right? It seems like the amount of memory to read is variable. Are there any other instructions that get a discount for reading a chunk of memory?
