Thread by @MikeToutonghi

#VerusIP - a truly decentralized inter-system protocol! Want to know how it works, its level of decentralization, and why it's superior?

Also, how does it secure cross-chain transactions?

And let's not forget about Verus's MEV-resistant DeFi's role in all this!

A 🧵
👇

1/ It all rests on establishing a “ground truth” or cryptographic “proof root” of one chain or system on another. This process is called notarization, and options include decentralized auto-notarization, notary-confirmed notarization, and centralized notarization, using VerusID.

2/ Notarizing with auto notarization or notary confirmed options are fee-based consensus processes involving permissionless chain validators and/or witnesses that are controllers of multisig, revocable, and recoverable VerusIDs, all to determine another system’s true proof root.

3/ The establishment of this root is a fundamental step in all cross-chain protocol options currently available in VerusIP. In no way does this notarization process involve approval, disapproval, ordering, or similar control of cross-chain funds or txes.

4/ Validators, (miners/stakers), start by entering notarizations into the blocks they mine or stake, called “earned notarizations”. Depending on the notarization protocol, other validators and witnesses may then agree or disagree with earned notarizations and eventually confirm.

5/ When confirmed notarizations from one chain are accepted on another, they follow more validation until mutual proof roots of each chain are confirmed on the other. These notarizations are then used to locally prove transactions from the other system.

6/ A separate import/export protocol rolls up exports on all chains as a normal part of mining and staking, and according to specific rules, which also support DeFi rollups and include MEV-resistance, system-specific transaction, identity, and currency aggregation & rate limits.

7/ Imported transactions w/ funds from one chain to another include validated proofs, and all rules for funds transfer are bound to ID namespaces, are the same rules for all types of proofs, involve only simple, auditable calculations/txes, and are supported on all PBaaS chains.

8/ Proof protocol options available in v1.0.8 are PBaaS, ETH, and ID-based (centralized). Enabling intersystem interoperability using those proof types. The protocol is generalized and can easily support other protocol types over time.

9/ PBaaS proofs use an updated version of the Blake2B Merkle Mountain Range (MMR) proofs that Verus has supported for years. Any input, output, zk-proof, user data, identity, currency, signatures, or any sub-part of a tx on any PBaaS chain can be proven cross-chain w/ PBaaS MMRs.

10/ ETH protocol proofs are based on the Ethereum PATRICIA Trie proofs, bound to the root of the ETH blockchain and further bound through the Verus Gateway definition, as all ETH-mapped currencies are, to the specific Ethereum contract to which the currency or gateway refers.

11/ ID-based proof protocol supports centralized, provable gateways using revocable, recoverable multisigs on any chain, where the multisig does approve transactions in/out. This centralized option, not our focus today, may suit govts/corps/NGOs & is further secured with VerusID.

12/ In order to import an export from another system onto a PBaaS chain in the Verus network, the export transaction and all components of that export transaction must be proven and their calculations validated for the import transaction to be accepted by the importing consensus.

13/ You may think, “That sounds great! Provable cross-chain w/consensus-based proofs, enabling us to prove another chain’s txes. Why is DeFi important for this?”

The kicker? DeFi, MEV-resistant DeFi more precisely, actually enables and helps secure decentralized cross-chain!

14/ If you want to send from chain A to chain B, where currency A is the security currency (proof of work/stake) for chain A and B for chain B, how do you get currency B on chain A to pay the import fees for your send?

15/ Without actually solving this problem, you cannot create a truly decentralized cross-chain protocol, as permissionless blockchain security fundamentally depends on the concept of fees being required for transactions to be entered. This is a bit of 🐔 &🥚.

16/ In today’s generally multisig, centralized bridges, you might have centralized options, and if all currencies are on your local Uniswap, you might also be OK, but what about actually decentralized, multichain interop? How to get currency B on chain A for your send to arrive?

17/ This is where bridge converters, liquidity baskets straddling both chains come in. When crossing from one chain to another, the converter provides automated liquidity for both the source and destination currencies, efficient enough to auto-convert fees from currency A to B.

18/ While any permissionless DeFi liquidity basket on Verus may be able to convert between currency A and B, “bridge converter” currencies are default converters easily and automatically chosen when sending across chains the chains they exist to serve.

19/ As all baskets do, bridge converters earn fees for LPs by converting currencies and registering functional sub-IDs. The fees, if defined thoughtfully, ensure that cross-chain operations have the fee liquidity needed for permanently supported & sustainable cross-chain flows.

#Verus #PBaaS, the provable, decentralized cross-chain solution for all, live on mainnet! Verus delivers the promise of decentralization, a rent-free, unlimited scale network with space for your community & projects. PBaaS is the true Internet of Value!

https://twitter.com/MikeToutonghi/status/1668438067978596353