RFC: ESIP-11 - Transferring (and bulk) of ethscriptions, through Blobs

[tunnckoCore]

Since we are going with CBOR for ESIP-8 #17, it makes transferring (bulk and not) even cheaper because the ethscription size will be static data:;rule=esip6, and blob space is cheap. This also allows for transferring to multiple different addresses in one go, which can be useful for AIRDROPS to a bunch of people.

It could be something like, CBOR containing transfers which is an array of to, transaction_hash objects.

{
  transfers: [
    { to_address: '0xd9F6...992f', transaction_hash: '0x0cbddcfda...53b7c99dc6'  },
    { to_address: '0x3e7a...e5b5', transaction_hash: '0x1234'  }
    { to_address: '0xF64b...46e8', transaction_hash: '0x567'  }
  ]
}

The from is clear, it's the creator of the blob transaction.

Currently the ESIP-8/CBOR creation should take this into account and only do its stuff when cbor.content is detected.

Here's my handling

const inputData = `0x${fromTxBlobs(blobs)}` as `0x${string}`;

const inputBytes = tryUngzip(hexToBytes(inputData));

// that's not ESIP-8-spec compliant, but i'm handling/support non-cbor-ed blobs too.
const data = inputData.startsWith('0xb90002') ? decodeCborX(inputBytes) : { content: hexToBytes(inputData) };

if (data.content) {
  data.content = tryUngzip(data.content);
  data.size = data.content.length;

  // raw json handling
  let rawJson;
  try {
    const str = bytesToString(data.content);

    rawJson = JSON.parse(str.startsWith('data:') ? str.slice(str.indexOf(',') + 1) : str);
    data.mimetype = 'application/json';
    data.content_json = rawJson;
  } catch {}

  if (!rawJson && data.mimetype && data.mimetype.includes('application/') && data.mimetype.includes('json')) {
    try {
      data.content_json = JSON.parse(bytesToString(data.content));
    } catch {}
  }
}

data.sha = sha256(inputBytes);
data.transaction_hash = txHash;

return data;

And because it's used just as "signaling layer" of changing state that already exists in the system (eg. db/history of ethscriptions ownership changes), these blobs can be skipped of persistrance - eg. not saving them in db like other blobs, cuz it's not really neaded. What will happen is that you'll add these transfers tovalid_transfers of the given ethscription in transaction_hash of the transfer object.

cc @RogerPodacter

[RogerPodacter]

Cool! I think if we want transfers we should probably have a generic flag that says “treat the blob as if it were the calldata” and then we could use the same format, which is more efficient anyway as it encodes the addresses as bytes instead of hex strings.

[CryptoPoltr]

Using blobs for accounting purposes is not a good idea due to their temporary nature.

[tunnckoCore]

@RogerPodacter Cool! I think if we want transfers we should probably have a generic flag that says “treat the blob as if it were the calldata” and then we could use the same format, which is more efficient anyway as it encodes the addresses as bytes instead of hex strings.

The "flag" is this cbor.transfers, eg. if the cbor has transfers instead of content, then it's considered transfer operation.

It cannot be just like the regular ESIP-5 bulk transferring, we can support it, but the idea is to be more clear and that with that we support sending to multiple recipients at the same time. The efficiency isn't a big deal here with blobs, that's why we can be a bit more explicit and do bigger jsons - A; and B - sure the to can be bytes instead, no worries.

@CryptoPoltr Using blobs for accounting purposes is not a good idea due to their temporary nature.

As i said in twitter, there are ,and will be more, services and apis and archival nodes that will always save that. It's not like apis or regular centralized services. There whole projects dedicated to just that - saving blobs, us included. CovalentHQ and EthPortalNetwork are examples.

[CryptoPoltr]

@tunnckoCore By relying on third-party projects, we risk losing data. I think blobs are best used for storing digital art content only.

[tunnckoCore]

@CryptoPoltr

It's absolutely the same imho. Whether you depend for the art or for transfering the art.. you still "trust" third parties which isn't an argument and case anyway cuz many will host blob data.

The key is to have as easy as possible ways to run indexers and dbs and make them sync between each other. Then it won't be a case of trust.