ESIP-8: Ethscription Attachments aka "BlobScriptions"

[RogerPodacter]

ESIP here: https://docs.ethscriptions.com/esips/esip-8-ethscription-attachments-aka-blobscriptions

Previous discussion here: #16, including significant contributions from @tunnckoCore.

[satlk]

good

[JacksonRGB]

question: wrong blob format?

there is no 0xb90002 prefix

const cbor = require('cbor');
const {toBlobs} = require('viem');
const fs = require('fs');

const imagePath = './logo.png'
const imageData = fs.readFileSync(imagePath);

const dataObject = {
  contentType: 'image/gif',
  content: imageData
};

const cborData = cbor.encode(dataObject);
const blobs = toBlobs({ data: cborData });


console.log(Buffer.from(cborData.slice(0, 50)).toString('hex'))
// => a26b636f6e74656e745479706569696d6167652f67696667636f6e74656e7459e79589504e470d0a1a0a0000000d49484452
console.log(Buffer.from(blobs[0].slice(0, 50)).toString('hex'))
// => 00a26b636f6e74656e745479706569696d6167652f67696667636f6e74656e740059e79589504e470d0a1a0a0000000d4948

[RogerPodacter]

@JacksonRGB b9 and a2 are both valid opening bytes for our cbor payloads as they are both different ways of expressing a mapping in cbor and our payload is a mapping. There might even be other ways to express our payload in cbor that I'm not aware of. Overall I don't think you can depend on any "magic bytes" to identify a CBOR document; you have to try decoding it and see if there's an error.

Fortunately in our case we only have to look at blobs for transactions that are valid ethscription creations (ie contain data URIs).

[tunnckoCore]

Fortunately in our case we only have to look at blobs for transactions that are valid ethscription creations (ie contain data URIs).

eg. they have at least the bare minimum of valid calldata ethscription data:;rules=esip6,

@JacksonRGB there is no 0xb90002 prefix

Seems like this is the prefix for tagged cbor, which i got cuz i decided to work with cbor-x library initially.

I think @RogerPodacter is rushing it and we should use tags but i guess it's okay.

[RogerPodacter]

Seems like this is the prefix for tagged cbor

What makes you say this? I'm pretty sure it's about different ways of encoding a mapping and has nothing to do with tags.

we should use tags

Open to suggestions! I don't think they really add anything here and I want to avoid having too many different ways of saying the same thing.

[benaadams]

Should call them "Ephemerals" rather than "BlobScriptions" or Ethemerals; as 18 days and are gone from the chain

[RogerPodacter]

@benaadams I like the name! But Ethscriptions indexers are required to store the data in perpetuity so BlobScriptions shouldn’t be ephemeral from the user’s standpoint. L2s also use ephemeral blobs to create a protocol with persistent state.

Resyncing from scratch could end up being annoying in both cases but I’m confident the blob data will be available from somewhere even if it’s not an Ethereum node.

But we will have to see!

[baalisgood]

I use https://blobscriptions.io/ to generate wallet address failed to create a blob after there was a problem, I try to turn out my ETH tokens, but encountered an error, the error I haven't seen before: {'code': -32000, 'message': 'address already reserved'}

[tunnckoCore]

@benaadams Should call them "Ephemerals" rather than "BlobScriptions" or Ethemerals; as 18 days and are gone from the chain

I like the name too. Nothing stops us to make a separate blob-based protocol that's not coupled with ethscriptions (because yes, there are limits and requirement just because of that). That was my initial idea to use blobs for - just an easy and simple protocol to create and trade ANY blob. It can still follow the same esip-8 spec (eg. minimal data uri calldata, and a CBOR-ed blobs), but could be ephemeral, the bonus would be that Ethscriptions could play as a permanent storage for that protocol too LOL.