You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just heard of Submarine Sends today, and read the documentation and smart contracts, so forgive me if my question or suggestion is naive.
Instead of using proofs or challenges as a mechanism to retrieve or trust the commit block, why not have the contract itself store the block number of the latest/last commit by the user. This can either be done via the constructor when it was deployed, or via a payable commit function.
Now, we want to be able to trust that the value of the public commitBlock was written to appropriately, so we just use EXTCODEHASH to check that the contract code actually does exactly that. We know what the contract code should always look like, given some fixed compiler version, so the deployed code's hash should be enough.
Am I missing something?
The text was updated successfully, but these errors were encountered:
Just heard of Submarine Sends today, and read the documentation and smart contracts, so forgive me if my question or suggestion is naive.
Instead of using proofs or challenges as a mechanism to retrieve or trust the commit block, why not have the contract itself store the block number of the latest/last commit by the user. This can either be done via the constructor when it was deployed, or via a payable
commit
function.Now, we want to be able to trust that the value of the public
commitBlock
was written to appropriately, so we just use EXTCODEHASH to check that the contract code actually does exactly that. We know what the contract code should always look like, given some fixed compiler version, so the deployed code's hash should be enough.Am I missing something?
The text was updated successfully, but these errors were encountered: