RFC: Better/alternative built-in transfer mechanism

[tunnckoCore]

Because the current, as i call it "raw", feels like "outside of the protocol". It's just a transaction hash in calldata. While it's simple and elegant, it's an absolute nightmare and worst thing of the whole protocol. You simply cannot, easily, back track the full transfer history of a given ethscription without depending on an API (on a given indexer directly).

You can see an ethscription contents and metadata, by simply asking the blockchain, but you cannot for the transfers history - the most crucial and important thing.

It bugs me since the beginning. And i think we talked about that in the discord.

We can use something like URI params. Both transfers will remain, better ban the original one tho but yeah.. if apps and services just start using the new one, thing will gradually migrate and be more easily trackable.

Something like

data:;transfer=true,<transaction_hash_without_0x>

This may seem simple, but over time it would simplify the things a lot. The way to create is basically replacing the 0x of a transaction hash with the hex of data:;transfer=true, eg prepending it.

Like so

0x 

# data:;transfer=true,
646174613a3b7472616e736665723d747275652c 

# ethscription/transaction hash
2bb9192fadf41cde7d50a96c4f1b7e6b7cab518cbc45aee4a9de732b535f221f

Not to mention that we definitely need separate endpoint for transfers history and make the main ethscription endpoint a static cached one - no current_owner, no content_uri, no previous_owner, and no transfers.

In an Etherscan-style app, what i plan for the WGW v2, we don't even need an indexer or hosting anything, or making requests to the official API -- no dependence on anything but the blockchain. I can just get the transaction hash and decode it and visualize it however i want. The only minus of that is i cannot show the transfers history on an ethscription page. I could use the api, which will respond me with a needlessly huge json blob cuz it also includes the content as base64. Think about bandwidth waste and snappiness of opening pages, eventho the api responses are cached.

Kinda related is the #9 ESIP-5 and #20 ESIP-11.

cc @RogerPodacter

---

Or another approach is the Facet-style with single-address, all transfers to happen through single address. Tho that will require to add the receiver to the calldata which kinda increases the cost a little bit but still.. having a single point of truth for all ethscriptions transfers history is huge plus.

---

In both cases, it can fallback to the official API.

[RogerPodacter]

Interesting! I definitely agree that a disadvantage of the current situation is that you can't distinguish an ethscription transfer from a random tx with 32 bytes in the calldata. At the same time, converting to a data uri (and UTF-8) would significantly increase the payload size, which cuts the other way.

Overall though I'm not sure how your proposal addresses the issue of needing to depend on an indexer. Even if every transfer used your format, in order to distinguish valid and invalid transfers you would still need to know the entire transfer history of an ethscription to see who owns it, and that still requires looking at the calldata of every tx since genesis.

In fact the same is true for non-ESIP-6 ethscriptions—you can't just look up content and metadata by tx hash because you can't know whether that hash corresponds to a valid non-dupe ethscription without indexing the entire history before it.

Thoughts?

[tunnckoCore]

@RogerPodacter: significantly increase the payload size

which payload size? the cost for transfer?

Overall though I'm not sure how your proposal addresses the issue of needing to depend on an indexer. Even if every transfer used your format

If most start using only the new format, which could be kinda easy because there's not much parties in the ecosystem which create ethscriptions and do transfers. In fact, Ordex don't even transfer, the ethscriptions always sit in escrow and they just change ownership in their db, only when user asks for unescrow they actually make a transfer.

If we hide the old option, and the major players just switch to use the new one, we can safely assume more and more will be "converted" to the new format. It could take time for sure, but once the majority were already moved at least once through the new format - future players can more easily scan (sync state) the whole chain independently.

If most are with the new format, it's significantly better, faster, and easier to scan the chain.

in order to distinguish valid and invalid transfers you would still need to know the entire transfer history of an ethscription to see who owns it,

yea kinda

---

My main problem is how incredibly hard is to actually sync to a current state, without depending on the official api. Sure, it's not going anywhere but.. still. If something happens, how one can actually reliably and safely resurrect the whole thing given only the initial block or something like that.

6 million ethscriptions is still kinda early and we can fix that mechanism. Ownership history is actually the biggest and the most important thing, we don't really even need to track and store anything else but that, and that part is in a terrible state :D

[RogerPodacter]

But how does your proposal make it easier to sync? Under your proposal, to derive the correct current state don’t you still have to examine every transaction since genesis one-by-one?

[tunnckoCore]

@RogerPodacter But how does your proposal make it easier to sync? Under your proposal, to derive the correct current state don’t you still have to examine every transaction since genesis one-by-one?

There are ways to filter the chain only for given calldata/input data. So you can just ask for data: and get everything about the whole protocol.

Sure, if they do that now, they won't get the whole state of things, but as i said, we are early and can change that. We can even incentivize users to do at least one new-format-transfer cuz a new player may not really need all the previous transfers, only need the most recent and the current owner.

Man, i regret/despise this transfer design so much.. it's killing me :D on otherwise perfect and minimalistic protocol :D

[tunnckoCore]

Or maybe the way is with what i call "on-demand" or "passive indexing". A new player jumps in, starts listening fresh without caring about syncing, and when detects new transfer it resolves that ethscription too and retro-adds it. I kinda did that for a while.

I should make a huge documentation on that, haha. With a one-click-deploy.

[RogerPodacter]

There are ways to filter the chain only for given calldata/input data.

Sure but there are also ways to find the exact state of any ethscription at any moment (the Ethscriptions Indexer)! What makes you open to one dependency but not the other?

when detects new transfer it

But it's not possible to detect new transfers without a full sync because you can't distinguish invalid ones from valid ones unless you know the full history.

[tunnckoCore]

Sure but there are also ways to find the exact state of any ethscription at any moment (the Ethscriptions Indexer)! What makes you open to one dependency but not the other?

A) It's not dependency in the usual sense, B) it's ruby, C) a monolith, D) still, we talk about people being able to start from scratch in building their own indexer in whatever language they want, and to do that they more likely would find a service that can filter the chain by /^data:/.

The point is if the ecosystem start slowly moving to new type of transfers one day at some point, when probably most ethscriptions would already been transferred at least once, it will be a lot easier for them to say "oh okay, just scan only for data:"

But anyway. It's terrible and something should change cuz currently it's practically very hard to even sync the whole state. If it is me, i'd start reading from the official v2 API in the reverse mode and populate the db.