Adding smart contracts functionality to the Coretime chain #96
Conversation
|
To expand more on this, wonder why don't we just create a new Contract Hub system parachain that is ready to XCM any other system parachains in the ecosystem? I saw there is a proposal for expanding the functionalities of the Asset Hub via contract execution as well: https://polkadot.subsquare.io/referenda/885 and I saw this is a conflict of interests while we keep making the system parachains more complicated instead of simplifying the way other L1 parachains can XCM to these system parachains. Let me know if this is not a correct place to start a further discussion. |
|
In my mind the complication this brings to coretime is mostly integrating one more pallet. While if we not do this, we push the complexity to the developers of smart contracts. People are working on making XCM easier and better integrated/accessible to smart contracts/ ...., but it will nevertheless always be a bit more complex than just calling a function, it will always stay asynchronous, it will always be much slower and it will always be of higher cost. Therefore it makes sense to stay on a chain where you can and only go cross chain when there is an actual need. E.g. getting funds to the Coretime chain to interact with the market. |
|
I am in favour of this. I think asking contract developers to deal with XCM is a big ask when there is essentially no need for this. Sharding is a tool for scalability but we are not there, yet. It is good that we have XCM once sharding is useful, though. |
| ## Testing, Security, and Privacy | ||
|
|
||
| ### Testing | ||
| - Comprehensive unit tests and integration tests should be developed to ensure the correct functionality of smart contracts. |
There was a problem hiding this comment.
This seems outside the scope of the RFC, since by definition we can't control what contracts people deploy. Could you clarify to state that the tests should cover the functionality of the contract virtual machine and interactions that it can have with the rest of the runtime?
There was a problem hiding this comment.
@joepetrowski thanks for catching that. By this I meant that there need to be tests that ensure that the broker pallet functionality that is for example exposed to the smart contracts has doesn't pose any vulnerabilities.
| ### Performance | ||
| - The introduction of smart contracts may impact performance due to the additional computational overhead. | ||
| - Optimization techniques, such as efficient gas fee mechanisms and resource management, should be employed to minimize performance degradation. |
There was a problem hiding this comment.
This should be pretty easy to mitigate by giving contracts a custom DispatchClass and limiting how much of the block they can consume, so we ensure some amount is always reserved for "core" Coretime functionality.
Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: joe petrowski <[email protected]>
|
Seems like the sentiment is overall positive for this proposal, could we maybe proceed with the voting process? |
| @@ -0,0 +1,102 @@ | |||
| # RFC-0002: Smart Contracts on the Coretime Chain | |||
There was a problem hiding this comment.
| # RFC-0002: Smart Contracts on the Coretime Chain | |
| # RFC-0096: Smart Contracts on the Coretime Chain |
| | | | | ||
| | --------------- | ------------------------------------------------------------------------------------------- | | ||
| | **Start Date** | 2024-06-09 | | ||
| | **Description** | Implement smart contracts on the Coretime chain | |
There was a problem hiding this comment.
| | **Description** | Implement smart contracts on the Coretime chain | | |
| | **Description** | Integrate smart contracts with the Coretime chain | |
There was a problem hiding this comment.
File name should be 0096, not 00xx
|
I think the RFC should specify that we want to deploy the same pallet that we deploy on AssetHub for contract execution. While this seems to be implied it should be explicitly stated in my opinion. This is important to make sure that we don't end up with two incompatible solutions and set of toolings. In this scenario runtime functionality will be exposed via pre-compiles. I assume that there will just be a different set of pre-compiles on AssetHub vs. Coretime. From the point if view of Solidity developers it is just a different set of .sol interface files they can make use of.
Once the open suggestions are addressed I can propose it. |
This RFC proposes adding smart contracts to the Coretime chain using platforms like Ethereum’s Solidity or Polkadot's Ink!. This will support automated region trading, dynamic pricing, and other advanced functionalities, expanding the chain's capabilities and fostering innovation. This suggestion follows discussions in PR #94.