ESIP-2 Discussion

[RogerPodacter]

Here we are discussing the ESIP in this file: https://github.com/ethscriptions-protocol/ESIPs/blob/main/esip-2-safe-smart-contract-ethscription-escrow-with-transferforpreviousowner.md

[toshtoss]

well, lgtm. In this example, the smart contract is responsible for broadcasting the occurrence of events, while the high-dimensional indexer determines which facts are valid. However, whether the block restrictions should be handled by the smart contract is something worth considering. Since users obtain the indexed results from the indexer, the indexer itself should ensure that the displayed data is deterministic and not subject to changes due to block reorganization.

[mikeahirsch]

@toshtoss The indexer will start indexing blocks right away and potentially blocks that will later get reorged. So we add a 5 block waiting period on the frontend after each transfer to guarantee it is where the indexer thinks it is. This onchain enforcement just makes it less of a suggestion to the frontend and actually enforced (at least when sending to the marketplace).

[starbt]

the smart contract example maybe have some problems. if Bob is the owner of escription id 0x123, Alice Deposits id 0x123 before Bob, Bob can't Deposits id 0x123 anymore. In the function _onPotentialEthscriptionDeposit, it can't detect if a previousOwner is the real owner.

[tunnckoCore]

@starbt true

[RogerPodacter]

@starbt this is definitely something we need to account for! However I believe we did so in _onPotentialEthscriptionDeposit because we store each ethscription id scoped to the person who claims to have deposited it in this line:

EthscriptionsEscrowerStorage.s().ethscriptionReceivedOnBlockNumber[previousOwner][potentialEthscriptionId] = block.number;

Here we are using the presence of a block number to indicate that a person has potentially deposited an ethscription, but it could easily be a boolean as in (pseudocode):

ethscriptionsMaybeDeposited[Alice][0x123] = true;
ethscriptionsMaybeDeposited[Bob][0x123] = true;

Here both deposits will succeed and both withdrawals will succeed as well (from the perspective of the contract) and in each withdrawal the contract will set ethscriptionsMaybeDeposited[Alice/Bob][0x123] = false;

On the protocol side, however, only one deposit is valid and only one withdrawal is valid, and the others are ignored.

Does this make sense? Thank you for your feedback!

[mikeahirsch]

if Bob is the owner of escription id 0x123, Alice Deposits id 0x123 before Bob, Bob can't Deposits id 0x123 anymore.

@starbt The contract allows anyone to send any bytes32 hash in the call data to the smart contract. If Alice sends one before Bob that's not a problem. The contract will receive both. The indexer will know that Bob was the previous owner so when Alice tries to transfer theirs out of the contract and the contract adds Alice's address as the previousOwner value in the event, the indexer will ignore it. Transfer events for Bob's will have Bob's address as the previousOwner and the indexer will validate that is true and consider it a legitimate transfer.

@tunnckoCore cc