steemit / smt-whitepaper

Smart Media Tokens whitepaper
29 stars 28 forks source link

Decentralized asset directory #107

Open theoreticalbts opened 7 years ago

theoreticalbts commented 7 years ago

After some intense discussion in Slack and a look at how token names are implemented in Ethereum (especially this EIP and the token registry docs for the Parity UI, we've started to discuss an alternative approach: a decentralized registry.

Basically it means a random-looking hex ID is used as an asset ID for on-chain operations, and translating that ID is UI-specific non-consensus code.

What I'd propose is that Steemit maintains its own directory file of reputable assets, publish (changes to) the directory file on-chain, and official UI's use Steemit's directory file by default.

At the blockchain level this doesn't give any special privileges to Steemit. And even at the UI level, Steemit's directory file would only be a default; the user would be free to use some other directory file, or refer to assets by ID rather than name.

realnedscott commented 7 years ago

Yes - agreed, we will move to HEX or decimal based IDs. UIs will maintain mapping files - hopefully one strong source will become consensus (e.g. Smart Media Token Alliance)

theoreticalbts commented 7 years ago

OK, so the next technical question is how to assign asset ID's.

I think Ethereum (like Bitcoin) references objects created by an operation using the txid of the transaction that created the object. In Steem there isn't currently a route to get this information into evaluators. Additionally it doesn't allow later ops in a tx from referencing an object created by an earlier op (you'd have a "cryptographic cycle" which can only be broken by breaking the hash function). This could be allowed if we have some "backreference" scheme. Which was at one point discussed early in development of Graphene, but never implemented.

Using object ID's like Graphene / Bitshares is also possible, but again it doesn't allow backreferences, and also isn't desirable.

I did a lot of thinking about the requirements yesterday. I think what it boils down to is "asset ID's are not user selectable nor mineable." So I think all we need to do is create a bounded-size queue of 9-digit (decimal) pseudo random numbers, it need not be a secure RNG. Then fix a (compile-time constant) seed, and take a single bit from H(fixed_seed + block_id) for 128 blocks whenever the queue is not full, that way each witness only adds 1 bit at a time, so the worst the last n witnesses can do is mine to choose between 2^n outcomes. And then asset registration must always use the first number from the queue.

I don't know that we want to enshrine algorithm forever in the blockchain rules, so I think consensus should allow regular nodes should reject it via RPC, but accept it in p2p tx's or blocks. Witnesses should reject it in their own block and other witness's blocks (otherwise all you have to do to circumvent the limitation is bribe a single witness).

As I said in the previous paragraph, I'm not sure we'll always use this particular algorithm, but I think it is important that we launch with an algorithm which is enforced by the witnesses. So from Day One UI's will properly query the blockchain for the name of the new asset.

Also, rather than having the ID implicitly assigned in a v-op, I think the ID should be explicitly specified in the first SMT related op they issue. This way multiple ops that modify the new SMT can be included in a single tx, which presents options to simplify the implementation of UI's for launching SMT's.