ESIP-3: Smart Contract Ethscription Creations Discussion

[RogerPodacter]

Read the ESIP here: https://docs.ethscriptions.com/esips/esip-3-smart-contract-ethscription-creations

[zdenham]

I'm a fan! My first thought goes to bulk ethscriptions in one tx... How might this work when the ethscriptionId is the txn hash?

Maybe for event-created ethscriptions the id could be defined by keccak256 hash of the inputs or something, so as to accommodate multiple creations in one tx

[zdenham]

Same question applies to ESIP1 & 2 I suppose, not sure how the protocol / indexer would handle multiple events firing in one transaction

[tunnckoCore]

Bulk things should be on separate esip. This one is good enough. LGTM ASAP! 😅

I have idea for how we can support multiple transfers in one transaction - just put multiple ethscription ids, comma separated or something. This will open the doors to interesting things like allowing to "deposit" multiple ethscriptions to a marketplace in one go, and other stuff.

But the bulk creation is a bit tricky. Ethscription id being the txn hash is vital and at the very core of the whole system so it's impossible to switch it. And i can't think of or see what could replace it.

Or.. yea, keccak of the from (the creator) + the to (the initial owner) + the input data. This way old/regular ethscriptions will have it (able to be calculated, and probably exposed thru the api).

[tyler2sv]

Bulk ethscription creation can use txhash+index, index can be the location index where the user stores multiple data in calldata, and also the event log index that can create ethscriptions by contract.

The ethscription id is used as the unique index of ethscription data, we can add i0 by default to the previous ethscription.

For example: 0xb1bdb91f010c154dd04e5c11a6298e91472c27a347b770684981873a6408c11c is equal to 0xb1bdb91f010c154dd04e5c11a6298e91472c27a347b770684981873a6408c11ci0

[RogerPodacter]

Thanks for the feedback, everyone!

ESIP-3 doesn't change the fact that each Ethereum transaction may have only one corresponding ethscription. If multiple aspects of a transaction constitute valid ethscription creations, calldata will be prioritized over events, and events with lower log indices will be prioritized over those with higher indices.

We could conceivably change this in the future but as @tunnckoCore suggests this is a real challenge.

We could modify the tx hash in some way to indicate the creation index (eg hash-idx), but then we must special case the common case where there is one ethscription in a tx with a rule like "no -idx means idx is 0") which is confusing. And even then it's nice to be able to say that ethscription ids are a fixed length (current marketplaces rely on this).

Using content hash solves these issues but it's not "natural" / discoverable from Etherscan like tx hash. Also if sacred cows are on the table I think the uniqueness thing, particularly for Dumb Contract ethscriptions, is less sacred than the one-per-tx thing.

In the end I think the mental model of an ethscription being able to do more than one thing is stronger than that of ethscriptions doing one thing and therefore our needing multiple ethscriptions in a single unit.

But in any case I don't think we should make the final call on that here.

[tunnckoCore]

@tyler2sv actually pretty simple and good idea, yea. A la Ordinals.

@RogerPodacter We could modify the tx hash in some way to indicate the creation index (eg hash-idx), but then we must special case the common case where there is one ethscription in a tx with a rule like "no -idx means idx is 0") which is confusing. And even then it's nice to be able to say that ethscription ids are a fixed length (current marketplaces rely on this).

Not that big deal, no that confusing, and not that hard code-wise. Plus, we are early and markets understandable/expected to adjust.

But yea, definitely a different ESIP, and we can just merge this ASAP. :100: :raised_hands:

[justrusk]

Bulk ethscription creation can use txhash+index, index can be the location index where the user stores multiple data in calldata, and also the event log index that can create ethscriptions by contract.

The ethscription id is used as the unique index of ethscription data, we can add i0 by default to the previous ethscription.

For example: 0xb1bdb91f010c154dd04e5c11a6298e91472c27a347b770684981873a6408c11c is equal to 0xb1bdb91f010c154dd04e5c11a6298e91472c27a347b770684981873a6408c11ci0

This is the exact way we implemented it, instead, we use : as separator, meaning it looks like 0xb1bdb91f010c154dd04e5c11a6298e91472c27a347b770684981873a6408c11c:0.

@zdenham You can try it on evm.ink We implemented what you wanted long time ago.

[justrusk]

Thanks for the feedback, everyone!

ESIP-3 doesn't change the fact that each Ethereum transaction may have only one corresponding ethscription. If multiple aspects of a transaction constitute valid ethscription creations, calldata will be prioritized over events, and events with lower log indices will be prioritized over those with higher indices.

We could conceivably change this in the future but as @tunnckoCore suggests this is a real challenge.

We could modify the tx hash in some way to indicate the creation index (eg hash-idx), but then we must special case the common case where there is one ethscription in a tx with a rule like "no -idx means idx is 0") which is confusing. And even then it's nice to be able to say that ethscription ids are a fixed length (current marketplaces rely on this).

Using content hash solves these issues but it's not "natural" / discoverable from Etherscan like tx hash. Also if sacred cows are on the table I think the uniqueness thing, particularly for Dumb Contract ethscriptions, is less sacred than the one-per-tx thing.

In the end I think the mental model of an ethscription being able to do more than one thing is stronger than that of ethscriptions doing one thing and therefore our needing multiple ethscriptions in a single unit.

But in any case I don't think we should make the final call on that here.

They are discoverable on ethscan as well. Here is example https://etherscan.io/vmtrace?txhash=0x849d325e36d670ae284d6102d2d5fad94caaa1543f14e016921244133d48713a&type=parity. Someone managed to inscribe 50 brc-20 tokens in one transaction

[tunnckoCore]

@justrusk great! I like this write up https://inscriptions.gitbook.io/docs/

It's the way it's supposed to be and should be - normalize (you call that prepare but yea) data first, then hash it. I always wondered why not to be possible contracts to create ethscriptions with just msg.sender.call(data).. And it was the very first intuitive thing i tried on day one.

Do you folks have discord or something?

And where can i see the ethscriptions that was done on that single transaction (besides the etherscan trace)? The site seems to not support /{id}:{index} (https://evm.ink/eip155:1/0x849d325e36d670ae284d6102d2d5fad94caaa1543f14e016921244133d48713a). I assume it shows just the first from all?

[RogerPodacter]

I agree there is something "impure" about having events with arbitrary names in the protocol.

At the same time, events are significantly cheaper (and cheapness is a big value of Ethscriptions), and trace_replayBlockTransactions would be an additional API / RPC call every Ethscriptions indexer would have to make to independently index data, which increases the overall cost of the protocol. In the case of the popular and performant Alchemy, trace_replayBlockTransactions is more than 10x costlier than the other two necessary calls (alchemy_getTransactionReceipts and eth_getBlockByNumber)

Finally, unless we want to do away with ethscriptions_protocol_TransferEthscriptionForPreviousOwner we're stuck with some event "impurity" anyway as you cannot capture the "for previous owner" semantics with the usual calldata transfer.

Regarding multiple ethscriptions per tx, I still believe the stronger approach is to give ethscriptions the ability to do more versus giving people the ability to create more ethscriptions.

The important thing is to capture the intent of the user, and this can be done within one ethscription. The user shouldn't have to worry about the mechanics of the steps of implementing this thing (for example, writing a for loop to mint 10 NFTs).

This transaction is a strong argument against multiple ethscriptions in a transaction and a strong argument for my position. Why should this person have to manually write out 50 JSON lines when the only thing changing between them is two digits? This ethscriptions should say something like mint(50) instead. Cheaper and clearer this way!