AEX-draft 12 off chain state

#1

This expansion points out possibility of using blockchain for maintenance off chain state.

You can use transaction payload to build off-chain state (most likely when it’s small)
You can use it to validate off chain data using hash in payload.

It does not enforce any communication protocol, besides:

  • using specific zero spend transaction to yourself
  • proposing to zip json payload of the transaction

It is probably one of the most common usages of blockchain, e.g. in Proof of Existence.
AEX standardizes way to emit data and reminds about this possibility, instead, growing
on-chain state.

Here is the draft:

#2

Lovely solution :ok_hand:t2:

Maybe “tag” is better field name than “dest”?

Also it’s probably too early, but you could plan for message fragmentation as well?

#3

Tag - good one, I am not sure about “dest”. What about “ns” (for namespace)? Tag is good, tho, because it’s short and self explanatory.

So, fragmentation can be part of the 3rd party protocol. If they wish (and pay) they can put a movie on chain, but should we interfere in the way they fragment it? Also, if we go deeper, we would end up in specifying another http (we would need headers, saying what’s length, which fragment it is, whats encoding…)

#4

Hi Michal,

Given that:

  • data fields has a random shape (pseudo-random sequence of characters)
  • You have only 2 short entries

I would argue that JSON+gzip will do any optimization. My intuition I that it’s bigger in size than any binary format (eg msgpack). Moreover, the readability argument doesn’t make sense because it’s the same effort to unzip it as to deserialize (eg for msgpack or bson). So, if you want to optimize then probably you we should choose different format than JSON .

Clarifications about AENS and Request for Requirments!
#5

it may also be fine to use the rlp format since it is already used in the project and is well supported by the available SDKs.

1 Like
#6

Robert & Andrea,

JSON+gzip was general guidance for any data that can be used by users. Surprisingly, it’s very space efficient and competes with major serialization formats like msgpack.

RLP indeed gives more value actually, as it is bit level specific and would let to build another layers on it.

Still, it’s a guidance. There is no harm if one cannot decode “data”. It can be even encrypted.

Advantage of JSON+Gzip is one can copy-paste it and decode in shell.
Advantage of RLP is ability to build crypto stuff on the top, but then there is no restriction to use it now.

What is an advantage of msgpack? It’s not crypto level specific and it’s the same regarding space efficiency. To decode it quickly we need some tool (sure, nothing big, even python shell, but still).

#7

Hi,
Thanks for responding.
Whats RLP?

As for serialization - there is no single answer. We can even see recently that some projects are developing yet another serialization format. Eg: Ethereum, Cosmos, Polkadot. Cosmos, in particular, spent 1 year developing their serialization protocol!

JSON is good for some parts. JSON+Gzip works well if you don’t deal too much with random data (so more like real world records, text, description, spreadsheets…).

There are reasons why some DBs are not using JSON+gzip. Most importantly like efficiency (JSON is slow, and then you need to add gzip on top of that). Probably efficiency will not be a case here, but it’s still worth to consider the following points:

  • are we going to design this standard for smart-contracts? If yes then I would argue that JSON+gzip is not a good solution (because it will consume an order of magnitude more gas).
  • readability - as explained above, JSON+gzip is not readable. Even if you will have handy gzip, bigger JSON records you will need to pretty print, because minimized ones are not readable.
  • if we just target with this standarad a method how to record an arbitrary data, then serialization (as, I think you were writing) may be only a recommendation.

It’s still worth to think if would like to use this mechanism for smart-contracts. I think today the smart-contract is not able to get information about a past transaction? So today this won’t be easily accessible for smart-contracts anyway.

#8

RLP is the Ethereum serialization standard. We initially started with msgpack for node functionalities (e.g. sync), but there was something broken (can’t recall now - was the order of elements in lists not guaranteed?) and finally we just moved to proven solution.

I will pass arguing on readability as it is very subjective. I still stand that JSON is readable due e.g. defualt browser support and pretty printing. For the space, I just recall experiments from the past and they were breaking even.

I think the key of mis-communication here is why to use it. I envisioned this AEX as method of external communication. Not relevant to the blockchain and surly not for contracts.

It was created in reaction, to requests to extend the protocol to support given functionality. For example how to deal with DNS for www. This is just standardizing how blockchain can be treated as key/val database (via spend payload) with authorization to changing the records (via self spend).

What did you have in mind? How protocol around spend payload can help contracts? For contracts RLP would be perfect and actually necessary. But does the problem exist for contracts given they exist in the same domain and can internally define the format of communication?

thanks for looking into the proposal!

#9

If you define a value proposition on-chain for that, then I guess it will be worth to make it working for smart-contracts as well - so the smart-contract is able to read it. It’s just an idea. But maybe here you want to make a proposal for storing a value on chain without involvement of a smart-contract. I’m just thinking loudly. On use-case related to DNS I can imagine is that a dapp want’s to interact with a domain and want’s to check a DNS record (eg: MX record - or something similar).