Content directory meeting summary

[Lezek123]

Open questions

• Which substrate version we need in order to have a stable evm pallet?

• Should we include full Frontier functionality in our runtime, with ethereum and ethereum-rpc modules? (it would certainly have a lot of benefits on the frontend side as described in Smart contracts content directory - implementation plan #1816)

• How does the runtime process ethereum transactions / blocks in case we use Frontier?

  • are ethereum transactions converted into substrate extrinsics?
  • since the ethereum transactions need to be signed it seems we cannot directly conntect them to a substrate accounts (I think substrate account owner does not own the private key to associated ethereum account). Should we have the ability to deposit from substrate account to any choosen evm account?
  • do ethereum blocks exist "separately" from substrate blocks - how they relate to each other how it affects the consensus?

• how are the weights computed for extrinsics like evm.call where the execution cost depends on the contract logic that lives inside the evm?

• who should pay the cost of gas consumed by runtime "hooks" that execute smart contract methods (ie. when registering new member)?

• since the council (or initially - sudo) can set any bridge contract address, can we avoid the possibility of breaking the runtime by setting a broken / malicous bridge contract address? (the runtime will try to call into it, for example, during member creation). If not - should the proposal stake in that case be close to that of a runtime upgrade?

• should we include any new proposals allowing the council ie. to initialize bridge contract with existing members or will we only rely on sudo in the initial phase? What if we need to split the initialization into multiple blocks?

Contracts implementation - issues in scope for initial release:

• Content directory smart contracts: Featured videos #1920 - we can use methods like setFeaturedVideos(_metadata), addFeaturedVideos(_metadata) etc. that don't enforce any specifc format of the metadata and make them executable only by the lead. The query node will then be fully responsible of validating and handling this _metadata (references to non-existent videos can probably be ignored. Once the video is deleted - we can use cascade delete on the database level or some other similar mechanism)
• Content directory smart contracts: Languages, categories and licenses #1919
• Content directory smart contracts: Channel ownership transfer logic #1915 - probably requiring transfer confirmation by recieving party will be the best approach here
• Content directory smart contracts: Channel handle uniqueness #1914
• Content directory smart contracts: Migration logic tests #1688
• The bridge contract initialization part of Content directory smart contracts: Create bridge contracts #1677 (executable by council/sudo)
• Content directory smart contracts: Splitting the logic #1922
• Content directory smart contracts: Actor-specific methods #1923

Contracts implementation - issues out of scope for initial release

• Content directory smart contracts: Series #1918
• Content directory smart contracts: Playlists #1917
• We can potentially exclude channels / videos limits to avoid the need for additional tests (should we still have customizable videos per channel limit?)

[ondratra]

• Which substrate version we need in order to have a stable evm pallet?

EVM pallet can be used with both Substrate we are using in Babylon and Olympia releases. Frontier's RPC compatibility is yet to be confirmed.

• Should we include full Frontier functionality in our runtime, with ethereum and ethereum-rpc modules? (it would certainly have a lot of benefits on the frontend side as described in Smart contracts content directory - implementation plan #1816)

Yes, we should. It will enable interaction with Metamask and other tools.

• How does the runtime process ethereum transactions / blocks in case we use Frontier?

• • are ethereum transactions converted into substrate extrinsics?

Ethereum transactions can be created from Substrate code (via extrinsic or inner logic). Also, Ethereum transactions can be received via Ethereum RPC (provided by Frontier).

• • since the ethereum transactions need to be signed it seems we cannot directly conntect them to a substrate accounts (I think substrate account owner does not own the private key to associated ethereum account). Should we have the ability to deposit from substrate account to any choosen evm account?

In our implementation, Substrate account ids are associated with the Ethereum addresses. If you control the account with id 000...001, you also control address 0x00...01 and vice versa. The only downside is that a bigger set of account ids (32 bytes) are mapped into a smaller set of Ethereum addresses (20 bytes), so multiple account ids are controlling the same address. But the 20 bytes number is so high that it shouldn't matter as account ids collision is improbable. Ethereum private keys are also 32 bytes long and are mapped into the same 20 bytes addresses, so this shouldn't be a problem for us as well.

• • do ethereum blocks exist "separately" from substrate blocks - how they relate to each other how it affects the consensus?

Blocks are executed in a virtual environment inside of Substrate. The currency is handled by native Substrate currency (there is no separate Ethereum currency), block info is stored into native logs, and contract code/state is saved into Substrate storage. Consensus shouldn't be affected because it is still achieved via rules written in Substrate.

• who should pay the cost of gas consumed by runtime "hooks" that execute smart contract methods (ie. when registering new member)?
  Transaction sender is paying the gas fee from the only currency that exists. We can donate this currency to anyone so we can make some transactions free or subsidized if we need it. There is no extra payment for miners/validators for executing EVM.

• since the council (or initially - sudo) can set any bridge contract address, can we avoid the possibility of breaking the runtime by setting a broken / malicous bridge contract address? (the runtime will try to call into it, for example, during member creation). If not - should the proposal stake in that case be close to that of a runtime upgrade?

It depends on how we can say that some contract is broken. We can programmatically check that contract fulfills some interface. We could maybe run some test inside another "Testing" smart contract, but other than that, we would need some consensus mechanism - maybe referendum or "second council". This seems like Quis custodiet ipsos custodes problem. I'll create a new issue for this.

• should we include any new proposals allowing the council ie. to initialize bridge contract with existing members or will we only rely on sudo in the initial phase? What if we need to split the initialization into multiple blocks?

This is yet to be researched/decided.

[bedeho]

The one thing still missing, which is quite important, is if the runtime calls a contract in the EVM,

1. where does the gas price come from and from what account is the ETH/JOY deducted to pay for the gas?
2. how do we properly assign weight to the runtime code which triggers this call?