Philosophy on what goes into the blockchain and what doesn't

Tokenscript Design
1

A snippet from one of @weiwu.zhang's documents (later extrapolated into a medium article) has gotten me thinking:

"People are blaming Ethereum blockchain congestion at the same time as they write smart contracts that forwards chat-chat messages." - Weiwu ZHANG

  1. The implementation of CryptoKitties makes it not possible to retrieve the balance (when defined as the kitties that an Ethereum address holds) easily. You have to walk through history or go to a 3rd party for it.

  2. ERC 1155 defines how a non-fungible token offloads metadata offchain hosted, accessible via a URL returned by a smart contract function. And it doesn't seem to describe any mechanism to ensure the authenticity of the data.

  3. Also side-chains and payment channels

Where do we draw the line of what goes on-chain, and what doesn't?

1 Like
2

Attestations helps exemplify some scenarios. Alice attesting to something of Bob, can be carried off-chain by Bob and presented when required. Alice can optionally store a hash of the attestation on-chain. But to revoke an attestation, that would have to be stored on chain (or at least a hash of it), and those checking Bob's attestation would have to check on-chain if it was revoked by Alice.

Gaming and advertising examples help explain use cases of payment-channels/side-chains. Eg, Raiden for broadcast-like subscription/payments, or micro-Raiden for game-sessions between participants.

1 Like
3

By asking about "philosophy", I believe, you are abstracting a bit and we should discard discussions like why costly bulk data shouldn't be on the blockchain.

Privacy

Public Blockchain is modelled after a trusted 3rd party without confidentiality. Anything that breach confidentiality, therefore, shouldn't be on the blockchain.

I know how "trust" and "confidentiality" sounds similar.

  • "trust" means "I ask you to keep my wife safe, not letting anything happen to her";
  • while "confidentiality" means "I ask you to keep my wife safe, not letting anyone know where she is".

In Don Quixote, a man broke his friend's trust by slept with his wife; but he didn't break the confidentiality since no one knew anything about it (hence putting the protagonist in a predicament). Blockchain can be considered the opposite of this untrustworthy character. It will not sleep with your wife (if your partner is a wife), but it will not keep things confidential.

Let's take a look at an example:

If Alice sends Bob an attestation attesting Bob's right to claim 1Eth from Alice's Wallet if Bob can prove that he owns email address bob@example·com

In designing the protocol, Bob should obtain a certficate of his email address that doesn't contain the email address itself. For how to achieve that check the protocol:

https://github.com/AlphaWallet/blockchain-attestation/blob/master/use-cases/email-address-attestation.md

We leave out the "practical" issues like "such a transaction shouldn't be posted on the blockchain until Bob obtained a certificate and claims that 1Eth, since it's wasteful to have 2 transactions to transfer 1 Eth".

Note that privacy sometimes include unlinkability. Borrowing from the Don Quixote example, that would be "I ask you to not to tell anyone where my wife is, and not to tell anyone that it was my commission". Some protocols are designed so that the data being commited to the blockchain is unlinkable, like the one in this paper:

Releases · SmartTokenLabs/attestation · GitHub (check attestation.pdf)

There are also availabiity and integrity considerations which I hope to write later. I'm glad you didn't ask "how data should be on the blockchain" since that is a blackhole of discusssion of "interoperability" and "transaction security" (e.g. form data in such a way that DvP security is achievable).