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

Support parallel runtimes through a pluggable architecture and abstracted interface layer #1353

Open
TheNewAutonomy opened this issue Feb 2, 2024 · 0 comments

Comments

@TheNewAutonomy
Copy link
Member

Feature Request

Is your feature request related to a problem? Please describe.
KVM is an extended EVM with support for pre-compiled assemblies as high performance contracts.
However, EVM processes smart contracts in a sequential manner, there are better alternatives in the markets such as SVM which runs smart contracts in parallel, tackling the problems of maintaining a consistent state when several contracts are running that rely on the same shared state at the same time.

There are also very distinct runtime environments with different bytecodes supported and different languages ranging from Rust to functional programming models. There are situations when it may be preferable, such as specialised side chains, when a network would want to run a non-deterministic runtime such as the .NET runtime environment with fully Turing complete logic written in C# or F#, compiled down to CIL.

Supporting multiple concurrent runtimes with very different rules opens up a big can of worms, such as does each runtime operate entirely independently or is there shared state. If there's a single ledger and unrelated runtimes updating that ledger, how do we ensure consistency of the ledger? In principle this is a similar challenge to a public database with multiple concurrent connections, with each connection being formed from a different client with different client business logic. Database state is protected. A similar approach would be needed but in principle we could allow very different runtimes to interact with a single shared ledger, possibly by abstracting away the runtimes behind a common interface layer.

In this scenario, you could have n instances of different runtimes taking transactions from their own mempool's and writing those changes out via a singleton interface layer, which maintains state regardless of the caller. In this model there is no limitation to the number or types of client runtime, you could even distribute runtimes across a network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: To do
Development

No branches or pull requests

1 participant