Discussion for OT-RFC-17

[NZT48]

Hi Tracers,

I am delighted to announce our latest RFC on OriginTrail integration with EVM-compatible blockchains.

You can access the PDF version of the RFC through the following link. Additionally, we welcome your feedback and comments on the proposal, which you can provide by opening a PR or reviewing the markdown file.

As always your feedback and comments are much appreciated.

Trace on!

[Valcyclovir]

Great to see DKG V6 going multichain!

This is a very welcome RFC and a great way to kickstart the adoption phase.

I personally think OP is a great contender for L2 with a lot of retail activity currently. Going back to ETH could be good, but we would face the same problems as V5 if fees go way up again.

Below is a quick poll result on the OTC Community channel.

[botnumberseven]

I'd suggest to consider a single stake option for our multi-chain future. Which means that for every action (e.g. publish an asset) chain-specific bridged TRAC is used. The only exception is stake verification. No matter what chain node runs on, the stake value is verified thru ETH chain.

There are a lot of benefits here: 1) Faster adoption. New chains can get a good enough number of nodes much faster, hence faster adoption. As adding node to a new chain will be just a question of creating a couple of wallets and updating node config. No need to have 50k more TRAC and bridge it to a new chain. 2) Damage reduction associated with bridges. Bridges are inherently risky, we've seen that over and over again. As more chains we spread over, as higher our chance to suffer from bridge hack. If there is no need to move stake TRAC thru bridges, then only TRAC required for operational expenses is moved thru bridges. In case of a bridge hack the damage would be significantly lower, several orders of magnitude lower. 3) More stable nodes environment. With single stake there will be no incentive for node runners (and delegators) to move from chain to chain chasing higher returns. On the contrary every node runner would have a incentive to run on all chains => more stable network. 4) Additional use cases opens. Let's say there is a great use case on chain A, but by design it's a low volume use case. And this volume cannot justify the existence on 100+ nodes on that chain. The returns are just not there for node runners to justify locking 50k. With single stake approach this use case will work just fine.

[TomRazouxSchultz]

I'd suggest to consider a single stake option for our multi-chain future. Which means that for every action (e.g. publish an asset) chain-specific bridged TRAC is used. The only exception is stake verification. No matter what chain node runs on, the stake value is verified thru ETH chain.

There are a lot of benefits here:

1. **Faster adoption**. New chains can get a good enough number of nodes much faster, hence faster adoption. As adding node to a new chain will be just a question of creating a couple of wallets and updating node config. No need to have 50k more TRAC and bridge it to a new chain.

2. **Damage reduction associated with bridges**. Bridges are inherently risky, we've seen that over and over again. As more chains we spread over, as higher our chance to suffer from bridge hack. If there is no need to move stake TRAC thru bridges, then only TRAC required for operational expenses is moved thru bridges. In case of a bridge hack the damage would be significantly lower, several orders of magnitude lower.

3. **More stable nodes environment**. With single stake there will be no incentive for node runners (and delegators) to move from chain to chain chasing higher returns. On the contrary every node runner would have a incentive to run on all chains => more stable network.

4. **Additional use cases opens**. Let's say there is a great use case on chain A, but by design it's a low volume use case. And this volume cannot justify the existence on 100+ nodes on that chain. The returns are just not there for node runners to justify locking 50k. With single stake approach this use case will work just fine.

Was just about to write this. Fully agree, and this is actually quite an existential point. Having single stake multi chain nodes actually is a big upgrade to the network that ensures stability/depth (more nodes per chain and less fluctuations over time) and breadth (more chains covered, lowering the barrier for apps on otherwise less popular chains)

[hottogo]

I was coming to write the same thing, but you wrote it out better than I could. Well done.

Instead, I will add these points to the discussion:

How will the Knowledge Asset Marketplace work between chains? Will all chains have access to the marketplace, therefore requiring a KA to be able to transact between chains? My suggestion is yes. The Knowledge Asset Marketplace should be multichain and a buyer should not be limited if they are on one chain or another from accessing certain knowledge assets. Therefore there needs to be a mechanism to update the status of a Knowledge Asset on one chain to be sold, or have it sent to a burn/lock address, to enable it to be owned on another chain. The data lives on the DKG which is multichain by design, but the Non-Fungible Token lives on a blockchain - this is the part that needs to have a mechanism for transfer between chains. These transfers need to be automatic and fast, as the marketplace won't succeed if it relies on manual transfers once a purchase of knowledge is made.

The other point is the cost to publish on specific chains. There is no doubt that the transaction costs need to use the native blockchain token to secure a transaction on that blockchain, there is also no doubt that TRAC needs to be spent to publish to the DKG from that chain. However building on the above quoted post, if nodes only need their stake on one chain, they will still need to earn Trac that is hosted on the other chains. Therefore you will find that TRAC needs to be bridged to each new chain (as outlined in the RFC re 5M+ TRAC) and publishers will need to use bridged TRAC and nodes will need to accept bridged TRAC. This will require both parties to have a wallet on each supported chain, funded with that chains token. This seems like a complicated and cumbersome solution as we add 10s, or 100s of chains but I can't think of a better way to do it - I hope others can. You could try to have a swap mechanism in place but that would need to be mulitchain to work. One to ponder.

Lastly I will add to the above quoted point that the chosen chain to hold node stakes obviously needs to be very reliable and trustworthy. Ethereum is a good choice on those points. There will also be some limited transactions on the chosen chain, as the slashing mechanism will need to still function to lock staked trac where a node is not complying with data holding requirements and uptime. Ethereum is an expensive chain but stake slashing happens rarely so this shouldn't be a problem.

[DalSlacker]

I'd suggest to consider a single stake option for our multi-chain future. Which means that for every action (e.g. publish an asset) chain-specific bridged TRAC is used. The only exception is stake verification. No matter what chain node runs on, the stake value is verified thru ETH chain.

There are a lot of benefits here:

1. Faster adoption. New chains can get a good enough number of nodes much faster, hence faster adoption. As adding node to a new chain will be just a question of creating a couple of wallets and updating node config. No need to have 50k more TRAC and bridge it to a new chain.
2. Damage reduction associated with bridges. Bridges are inherently risky, we've seen that over and over again. As more chains we spread over, as higher our chance to suffer from bridge hack. If there is no need to move stake TRAC thru bridges, then only TRAC required for operational expenses is moved thru bridges. In case of a bridge hack the damage would be significantly lower, several orders of magnitude lower.
3. More stable nodes environment. With single stake there will be no incentive for node runners (and delegators) to move from chain to chain chasing higher returns. On the contrary every node runner would have a incentive to run on all chains => more stable network.
4. Additional use cases opens. Let's say there is a great use case on chain A, but by design it's a low volume use case. And this volume cannot justify the existence on 100+ nodes on that chain. The returns are just not there for node runners to justify locking 50k. With single stake approach this use case will work just fine.

This spells it all out perfectly Critical mass on multiple chains won't happen concurrently if 50k TRAC is needed for each node on each one I suppose the question becomes- how many nodes are needed on a given network to deem it secure? At least dozens... realistically more. That won't happen on random chains with 50k stake necessary

[Valcyclovir]

I'm a bit on the fence on the comments above about a single stake system.

While it does sound enticing for all the reasons mentioned above, I believe some asset publishers would want their data holders to hold their tokens on the same chain as the publisher as collateral for security reasons.

For example, if something were to happen to Ethereum and the single stake mechanism is on that chain, that would jeopardize asset publishers who used different L0s such as Polkadot to publish assets. Since RFC16, native TRAC on Polkadot is a closed system and will remain so, and if a hack ever happens on the EVM side, the native TRAC on Polkadot is safeguarded and asset publishers who opted for Polkadot security would not be affected.

As unlikely as the above sounds, as the crypto space expands we are bound to find more L0s and more situations where the asset publishers want their assets to be safeguarded on a specific ecosystem.

There is also the idea of allowing network participants to use any chains, bridges, for both staking and publishing, in true Web3 fashion. Limiting node runners to one specific chain is against the idea of multichain and Web3.

If asset publishers are allowed to publish on any supported chains, why can't node runners choose to stake on their desired chain?

[DalSlacker]

I'm a bit on the fence on the comments above about a single stake system.

While it does sound enticing for all the reasons mentioned above, I believe some asset publishers would want their data holders to hold their tokens on the same chain as the publisher as collateral for security reasons.

For example, if something were to happen to Ethereum and the single stake mechanism is on that chain, that would jeopardize asset publishers who used different L0s such as Polkadot to publish assets. Since RFC16, native TRAC on Polkadot is a closed system and will remain so, and if a hack ever happens on the EVM side, the native TRAC on Polkadot is safeguarded and asset publishers who opted for Polkadot security would not be affected.

As unlikely as the above sounds, as the crypto space expands we are bound to find more L0s and more situations where the asset publishers want their assets to be safeguarded on a specific ecosystem.

There is also the idea of allowing network participants to use any chains, bridges, for both staking and publishing, in true Web3 fashion. Limiting node runners to one specific chain is against the idea of multichain and Web3.

If asset publishers are allowed to publish on any supported chains, why can't node runners choose to stake on their desired chain?

Let node runners stake on their desired chain, but let their stake be a total of 50k (or more) to allow multi chain to flourish

[Valcyclovir]

This doesn't solve the problem of asset publishers wanting their asset holders to have a collateral on their preferred chain. An asset publisher who only wants to use the security provided by Polkadot would not be thrilled to have a node runner staking 50k on Ethereum and holding their asset.

[Valcyclovir]

@NZT48 I submitted a PR for Optimism, and I was hoping to follow through and test submit a tx of TRAC to OP chain. Our token seems to be compatible as per https://static.optimism.io/optimism.tokenlist.json but after trying to use their bridge https://app.optimism.io/bridge/deposit I notice TRAC is not recognized and I need to follow these instructions: https://github.com/ethereum-optimism/optimism-tutorial/tree/main/cross-dom-bridge-erc20 in order to send TRAC over to OP. Am I doing this wrong, or are we expecting 5M TRAC to be sent to OP using this way before the PR is considered?

[BLITOW]

If we are connecting the dkg to rollups, we should only use the native bridge. On OP rollups this has a deley of 7 days, but the increase in security should mitigate this downside.

I don't think it's a good idea to start bridging to EVM compatible side chains using third party bridges. It's to early and to big of a risk at this stage. Hard no on BNB and Polygon(sidechain, zk EVM ok).

Basically no third party bridges, there are to much risks involved. Rollups are also not fully decentralised right now and are arguably not even battle tested yet, so there is already a big risk factor here. Lets not introduce more unnecessarily!

Would be interesting to consider rolling up OTP to other chains. Making it a bridge hub for the DKG with the security of polkadot. Mangata is working on something like this

[DalSlacker]

This doesn't solve the problem of asset publishers wanting their asset holders to have a collateral on their preferred chain. An asset publisher who only wants to use the security provided by Polkadot would not be thrilled to have a node runner staking 50k on Ethereum and holding their asset.

I don't think that is an actual issue When I've got my business data hosted by Google Cloud, it doesn't mean that I'll be turned off from dealing with other Corp infrastructure hosted on AWS I don't believe that tribalism related to invisible infrastructure providers is significant