search

OmniLayer / spec

Omni Protocol Specification (formerly Mastercoin)
The Unlicense
341 stars 118 forks source link

[Discussion] On-chain protocol layer #356

Open bvbfan opened 1 year ago

bvbfan commented 1 year ago

Currently protocol layer embed data via fake address (Class A), multi-sig transaction (Class B) or payload after OP_RETURN. The business logic is in omnicored which impacts mass adoption in well-known wallets. To accelerate decentralization including 3rd party adoption protocol may expose a bitcoin like script (similar to K lang) instead of payload after OP_RETURN. It potentially exposes a contract between couple of parties, set of rules/activations/consensus hash (restricted to exodus address). It means protocol upgrades is deployed by protocol owner, to prevent bad interpretation business logic needs to deployed on-chain as well.

  1. WebAssembly compiled library could be incorporated in witness script (ordinals like) and live on-chain.

    • Limitation: if it doesn't run in the browser it needs a VM. The easy integration will be a shared library which is platform specific.

  2. JS library (compressed) like new Ordinals feature.

    • Limitation: js interpreter could be vulnerable

Either way interpreter needs to be stateless, that could lead to consensus vulnerability.

msgilligan commented 1 year ago

In designing a next-generation Omni architecture, I think there are three related issues we need to address:

  1. Mechanisms for on-chain and off-chain data storage.

Note that Omni from the beginning has used off-chain storage: the (unfortunately, non-updatable) URL links for each Smart Property. On chain storage has migrated from Class A to Class B to Class C/OP_RETURN.

We may want to take advantage of TapRoot scripts like Ordinals, but I believe we should be better Blockchain citizens and limit the usage of on-chain storage by providing a standard/supported/recommended option for storing larger data items off-chain.

  1. Mechanisms for on-chain and off-chain transactions.

Lightning is the obvious choice here, but new technologies like Ark sound promising and should be considered. Changes to the core protocol to better support off-chain transactions are likely needed.

  1. Scripted smart contracts with on-chain and/or off-chain storage.

Any contracts used by Omni Core to determine a global "Omni consensus" would need to be on-chain, but off-chain contracts could be used for settling off-chain transactions, with the necessary information being published on-chain as part of finalization.

In addition, of course, we must choose a scripting language/VM. I would recommend we look at the Bitcoin-centric solutions here as a first step.

bvbfan commented 1 year ago

We could introduce a self-validating transactions. It's a transaction which includes, after OP_RETURN zero knowledge proof, which means it will be a self-proving entity a transaction data + hash of changes.

  1. To prevent miner to select transactions in unwanted order, all transactions related to specific address needs to reuse outputs of its ancestor one, so if a parent tx is somehow invalidated all descendants will be invalid by bitcoin. So it will prevent nuances in transaction processing
  2. A ZK proof is merkle root hash of corresponding data structure which tx will affect enters the Omni layer
  3. Off-chain data will be validated by applying the tx and verify the zk proof to match actual merkle root hash of the data structure
  4. On-chain data will limited to zk proof + omni layer payload after OP_RETURN or if needed witness script
  5. On-chain consensus (a monolithic distributed consensus) could offer stateless parsing/validating omni transactions based on client input. (optional)