Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] On-chain protocol layer #356

Open
bvbfan opened this issue Jun 21, 2023 · 2 comments
Open

[Discussion] On-chain protocol layer #356

bvbfan opened this issue Jun 21, 2023 · 2 comments

Comments

@bvbfan
Copy link

bvbfan commented Jun 21, 2023

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.
  1. 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
Copy link
Member

msgilligan commented Jul 6, 2023

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
Copy link
Author

bvbfan commented Jul 7, 2023

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants