Add Oasis Sapphire Mainnet chain

[matevz]

Adds the confidential Oasis Sapphire Mainnet chain 23294.

Merge after the Sapphire Mainnet endpoint is officially announced.

_{View in Huly HI-753}

[matevz]

I would appreciate, if someone could bump upstream chains.json (looking for this addition ethereum-lists/chains#2064). @kuzdogan ?

[matevz]

The immutable smart contracts will be tricky in Sapphire, because any function call data (including the one that is passed to the contract constructor) are confidential. In this case the Sapphire endpoint will return all zeros in place of the constructor parameters in deployedBytecode field.

[kuzdogan]

Bumped chains.json, you can merge from or rebase onto staging.

To make things clear: if you ask for the tx.input using eth_getTransactionByHash will you get all zeros? I couldn't really understand where the constructor parameters fall here because constructor arguments are appended at the end of the creation bytecode and are not in deployedBytecode field.

[matevz]

To make things clear: if you ask for the tx.input using eth_getTransactionByHash will you get all zeros? I couldn't really understand where the constructor parameters fall here because constructor arguments are appended at the end of the creation bytecode and are not in deployedBytecode field.

No, eth_getTransactionByHash will return you an encrypted transaction.

When running the test, this error is reported

sourcify/services/verification/src/services/Injector.ts

Line 240 in d0882a5

match.message = "The deployed and recompiled bytecode don't match.";

I added some debugging output here:

sourcify/services/verification/src/services/Injector.ts

Line 176 in d0882a5

deployedBytecode = await getBytecode(

And noticed the following:

deployedBytecode:
0x608060405234801561001057600080fd5b50600436106100415760003560e01c806357de26a41461004657806379d6348d146100c9578063ced7b2e314610184575b600080fd5b61004e6101a2565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561008e578082015181840152602081019050610073565b50505050905090810190601f1680156100bb5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b610182600480360360208110156100df57600080fd5b81019080803590602001906401000000008111156100fc57600080fd5b82018360208201111561010e57600080fd5b8035906020019184600183028401116401000000008311171561013057600080fd5b91908080601f016020809104026020016040519081016040528093929190818152602001838380828437600081840152601f19601f820116905080830192505050505050509192919290505050610244565b005b61018c61025e565b6040518082815260200191505060405180910390f35b606060008054600181600116156101000203166002900480601f01602080910402602001604051908101604052809291908181526020018280546001816001161561010002031660029004801561023a5780601f1061020f5761010080835404028352916020019161023a565b820191906000526020600020905b81548152906001019060200180831161021d57829003601f168201915b5050505050905090565b806000908051906020019061025a929190610282565b5050565b7f000000000000000000000000000000000000000000000000000000000000007b81565b828054600181600116156101000203166002900490600052602060002090601f0160209004810192826102b857600085556102ff565b82601f106102d157805160ff19168380011785556102ff565b828001600101855582156102ff579182015b828111156102fe5782518255916020019190600101906102e3565b5b50905061030c9190610310565b5090565b5b80821115610329576000816000905550600101610311565b509056fea26469706673582212200f4b79ce4268a474314f15ab80925bd78deed6af2213db6b41d15da4ec81536564736f6c63430007040033

recompiled.deployedBytecode:
0x608060405234801561001057600080fd5b50600436106100415760003560e01c806357de26a41461004657806379d6348d146100c9578063ced7b2e314610184575b600080fd5b61004e6101a2565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561008e578082015181840152602081019050610073565b50505050905090810190601f1680156100bb5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b610182600480360360208110156100df57600080fd5b81019080803590602001906401000000008111156100fc57600080fd5b82018360208201111561010e57600080fd5b8035906020019184600183028401116401000000008311171561013057600080fd5b91908080601f016020809104026020016040519081016040528093929190818152602001838380828437600081840152601f19601f820116905080830192505050505050509192919290505050610244565b005b61018c61025e565b6040518082815260200191505060405180910390f35b606060008054600181600116156101000203166002900480601f01602080910402602001604051908101604052809291908181526020018280546001816001161561010002031660029004801561023a5780601f1061020f5761010080835404028352916020019161023a565b820191906000526020600020905b81548152906001019060200180831161021d57829003601f168201915b5050505050905090565b806000908051906020019061025a929190610282565b5050565b7f000000000000000000000000000000000000000000000000000000000000000081565b828054600181600116156101000203166002900490600052602060002090601f0160209004810192826102b857600085556102ff565b82601f106102d157805160ff19168380011785556102ff565b828001600101855582156102ff579182015b828111156102fe5782518255916020019190600101906102e3565b5b50905061030c9190610310565b5090565b5b80821115610329576000816000905550600101610311565b509056fea26469706673582212200f4b79ce4268a474314f15ab80925bd78deed6af2213db6b41d15da4ec81536564736f6c63430007040033

If you carefully compare the two, you can notice the constructor argument 0x7b (123) is missing in the latter output. So I assumed the issue happened somewhere before, where it tried to fetch constructor arguments by decoding the creation transaction and that failed, thus leaving constructor arguments all zero.

[matevz]

This issue only persists for immutable contracts. Perhaps we could have a flag in sourcify-chains.ts, if the chain supports immutable contracts verification or not. And when the user would want to verify an immutable contract on a chain that doesn't support those, he should get an error (which is correct).

[marcocastignoli]

Perhaps we could have a flag in sourcify-chains.ts

I don't know if I understood it correctly, but I think there are no problem about implementing this feature.

Also, I think to make things more clear you could give us an example of eth_getTransactionByHash result. Thanks.

[kuzdogan]

I've only been able look at this now. To summarize:

deployedBytecode:
0x608060405234801561001057600080fd5b50600436106100415760003560e01c806357de26a41461004657806379d6348d146100c9578063ced7b2e314610184575b600080fd5b61004e6101a2565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561008e578082015181840152602081019050610073565b50505050905090810190601f1680156100bb5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b610182600480360360208110156100df57600080fd5b81019080803590602001906401000000008111156100fc57600080fd5b82018360208201111561010e57600080fd5b8035906020019184600183028401116401000000008311171561013057600080fd5b91908080601f016020809104026020016040519081016040528093929190818152602001838380828437600081840152601f19601f820116905080830192505050505050509192919290505050610244565b005b61018c61025e565b6040518082815260200191505060405180910390f35b606060008054600181600116156101000203166002900480601f01602080910402602001604051908101604052809291908181526020018280546001816001161561010002031660029004801561023a5780601f1061020f5761010080835404028352916020019161023a565b820191906000526020600020905b81548152906001019060200180831161021d57829003601f168201915b5050505050905090565b806000908051906020019061025a929190610282565b5050565b7f000000000000000000000000000000000000000000000000000000000000007b81565b828054600181600116156101000203166002900490600052602060002090601f0160209004810192826102b857600085556102ff565b82601f106102d157805160ff19168380011785556102ff565b828001600101855582156102ff579182015b828111156102fe5782518255916020019190600101906102e3565b5b50905061030c9190610310565b5090565b5b80821115610329576000816000905550600101610311565b509056fea26469706673582212200f4b79ce4268a474314f15ab80925bd78deed6af2213db6b41d15da4ec81536564736f6c63430007040033

recompiled.deployedBytecode:
0x608060405234801561001057600080fd5b50600436106100415760003560e01c806357de26a41461004657806379d6348d146100c9578063ced7b2e314610184575b600080fd5b61004e6101a2565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561008e578082015181840152602081019050610073565b50505050905090810190601f1680156100bb5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b610182600480360360208110156100df57600080fd5b81019080803590602001906401000000008111156100fc57600080fd5b82018360208201111561010e57600080fd5b8035906020019184600183028401116401000000008311171561013057600080fd5b91908080601f016020809104026020016040519081016040528093929190818152602001838380828437600081840152601f19601f820116905080830192505050505050509192919290505050610244565b005b61018c61025e565b6040518082815260200191505060405180910390f35b606060008054600181600116156101000203166002900480601f01602080910402602001604051908101604052809291908181526020018280546001816001161561010002031660029004801561023a5780601f1061020f5761010080835404028352916020019161023a565b820191906000526020600020905b81548152906001019060200180831161021d57829003601f168201915b5050505050905090565b806000908051906020019061025a929190610282565b5050565b7f000000000000000000000000000000000000000000000000000000000000000081565b828054600181600116156101000203166002900490600052602060002090601f0160209004810192826102b857600085556102ff565b82601f106102d157805160ff19168380011785556102ff565b828001600101855582156102ff579182015b828111156102fe5782518255916020019190600101906102e3565b5b50905061030c9190610310565b5090565b5b80821115610329576000816000905550600101610311565b509056fea26469706673582212200f4b79ce4268a474314f15ab80925bd78deed6af2213db6b41d15da4ec81536564736f6c63430007040033

If you carefully compare the two, you can notice the constructor argument 0x7b (123) is missing in the latter output. So I assumed the issue happened somewhere before, where it tried to fetch constructor arguments by decoding the creation transaction and that failed, thus leaving constructor arguments all zero.

It is expected the part in onchain deployed bytecode (000000000000000000000000000000000000000000000000000000000000007b) to differ from the recompiled d
deployed bytecode (0000000000000000000000000000000000000000000000000000000000000000) as the recompiled does not yet have it's constructor run, and therefore its immutables put in place. This makes verification with deployed bytecode difficult for immutables.

As a workaround we try comparing the creation bytecodes. We compare the recompiled creation bytecode against the tx.input of the transaction that created this contract. The problem with Oasis Sapphire, as you mentioned, is it doesn't return the raw tx.input but an encrypted data. So we can't use this method either.

We recently introduced another verification method with "bytecode simulation" #864 that executes the compiled creation bytecode. It should be possible to verify the given contract with this method. However this is currently not integrated in the tests. We should include this as a separate verification.

About having a variable in sourcify-chains.ts, we have the results of the tests documented here: https://docs.sourcify.dev/docs/chains/ One can see if the chain supports the immutable verification. Do you think this is not clear or is there a better way you think to demonstrate this? After integrating the new verification method to tests, there will likely be 2 immutable columns: with tx hash and with context variables.

[matevz]

FYI the new Sapphire 0.4.0 also supports non-confidential contract calls. Creating a confidential contract with a non-confidential transaction should now enable Sourcify to fully verify the contract. I'll make a fix shortly.

[matevz]

I used unencrypted contract create transaction now and seems to work fine with sourcify CI. Requesting re-review.