Welcome to Episode III of our L1X Deep Dive Series, where we unravel the intricacies of the L1X Virtual Machine (L1X VM), with the expert, Kevin Coutinho.
Join us as we embark on a journey through the complexity of the L1X VM, designed to offer a secure and deterministic environment. He will discuss its role in ensuring the integrity of transactions and blocks within the blockchain network.
Discover how the L1X VM sets new standards for smart contract execution, providing an isolated environment that safeguards against interference, thus guaranteeing the reliability and efficiency of the platform for developers and users alike.
WATCH THE FULL AMA
Section 1. Unveiling L1X Virtual Machine: Key to Blockchain Evolution
Kevin focuses on the importance of the Virtual Machine (VM) in layer one solutions. Having a scalable and secure virtual machine is crucial for the success of a blockchain protocol. Kevin, an expert in L1 XVM, explains that the VM is like the engine of a car, propelling everything in the system.
The session will cover the Node framework, contract types, compilation flow, execution flow, contract executor, opcode table, fee calculation, database manager, and storage instructions. The goal is to provide a comprehensive overview of the L1X infrastructure and the VM to help the community understand its utility and sustainability.
Section 2. The significance of VMs in contract execution
Without a VM, contract execution could yield inconsistent outcomes, jeopardizing the deterministic essence of blockchain operations. Serving as the central hub or 'brain' of the blockchain network, the VM guarantees that transactions occur in a validated and consistent manner. Various contract types, such as L1X VM, L1X EVM, and XSTO contracts, interface with the VM to manage transactions and uphold the blockchain's state. Developers harness languages like Solidity and Rust to deploy contracts, which are then compiled into WebAssembly to ensure compatibility with the target architecture. This compilation process involves translating developer code into a format intelligible to computers, ensuring seamless interoperability and efficiency in executing smart contracts across the blockchain network.
Section 3. Unlocking WebAssembly's Potential
The conversation delves into the advantages of utilizing WebAssembly (WASM) over JavaScript for browser-based execution. WASM offers portability and can be deployed in environments where languages like C and Rust cannot be directly executed. It proves particularly beneficial for resource-intensive applications such as games developed with engines like Unity. Notably, WASM boasts a smaller size due to its omission of location information storage, resulting in swifter execution, especially in just-in-time compilation scenarios. Additionally, explores WASM's utilization in decentralized nodes, IoT devices, and the imperative to render WASM code compatible with eBPF for Edge Computing devices. A compiler is in development to seamlessly convert WASM to eBPF while upholding security protocols crucial for smart contracts.
Section 4. Streamlining Smart Contract Execution with LLVM IR
The discussion delves into the complex process of converting WebAssembly bytecode from smart contracts into LLVM IR for execution. This method enables smooth execution of future smart contract versions across different architectures, eradicating the need for maintaining multiple versions. This compilation process not only enhances scalability and interoperability but also proves crucial for scenarios where smart contract execution on IoT devices is required. Stressing the importance of reducing computational burdens on nodes and shifting responsibilities to devices, the conversation highlights the role of zero-knowledge proofs in achieving this aim. It also touches upon HashLock's efforts in auditing contracts and upcoming discussions focused on ensuring code quality. Finally, it explains why a custom VM infrastructure is being built for long-term compatibility and emphasizes the importance of runtime execution in improving bytecode processing efficiency.
Section 5. Navigating the Compilation Flow
The discussion delves into the compilation flow of LLVM IR compiled to eBPF bytecode, operating within the eBPF system and interfacing with the node, serving as the database. The VM within this system relies on robust state management to ensure secure transactions by communicating with the database driver and the on-chain tree on the L1X Node. It conscientiously assesses its limitations and verifies balances before executing transactions. The speaker addresses community inquiries regarding the polyglot nature of the L1X VM, the security of hash lock orders, Bitcoin transaction scalability, and potential applications of the technology beyond Web3. They underscore the significance of the translation process from web assembly bytecode to LLVM IR and eBPF, highlighting its achievements and the prospect of partnerships with companies like Fitbit and Google Nest. Furthermore, Kevin explores the role of the X-Talk infrastructure and network sharding in scaling Bitcoin transactions, concluding with insights into the intricate development process and its underlying complexities.
Section 6. Prioritizing Scalability and Innovation
It delves into the complexities of constructing a layer one solution, emphasizing the decision to eschew shortcuts such as replicating the EVM (Ethereum Virtual Machine) due to scalability constraints. Kevin articulates the imperative of redirecting computation from centralized services back to devices, underscoring the significance of leveraging zero-knowledge and cryptographic algorithms for execution. Additionally, the discussion touches upon the development of a WebAssembly to LLVM IR conversion tool, illustrated through an anecdote involving a dialogue with a developer from Samsung. Kevin underscores the importance of establishing robust underlying technology as a foundational step before addressing other aspects. Furthermore, he elucidates the execution flow of a contract utilizing the L1X VM stack, highlighting the utilization of an L1X SDK for code composition and compilation, along with the pivotal role of an SDK macro in simplifying low-level calls for developers.
Section 7. Navigating Smart Contract Development
It is discussed the process of compiling, deploying, and executing smart contracts on the blockchain using system-level calls. It explains the compilation process, deployment on the node, execution by the VM, and interaction with the on-chain tree. Differences between eBPF and rBPF bytecode, as well as the concept of relocation for storing information in the blockchain. It emphasizes the use of SDK to build contracts and highlights the role of higher-level system calls and on-chain collections. The CIS (Computer Instruction Set) is explained as four types of communication methods between developers and processors: register API, storage, context, and miscellaneous APIs. The importance of emitting events instead of storing data for cost efficiency in smart contract development is also mentioned.
Section 8. Demystifying Storage in Smart Contracts and Blockchain Technology
the concept of storage within smart contracts and blockchain technology is explored. It explains how the register loads up storage information to make data readily available for the VM. The example given is similar to how apps on a phone open faster when already loaded in the register. The storage API allows for low-level system calls to store information in the state, with only smart contracts having the authority to make these calls. Smart contracts have explicit control over the database, preventing direct changes that could disrupt the state tree or root hash. The context API is described as handling input and output operations, such as sending information as output or passing values between functions in a contract. Miscellaneous APIs like Panic help manage transaction fees and errors in the consensus architecture. Logs, events, and emitting messages are also discussed as part of the miscellaneous APIs. The integration of L1X VM and EVM with Hardhat, a tool for compiling, testing, and deploying contracts, is highlighted, providing RPC endpoints for interaction. The importance of maintaining independence between the VM and the database for updates is emphasized for the proper functioning of the L1X VM and EVM flow.
Section 9. Navigating Database Updates with EVM
The discussion delves into the process of database updates facilitated by the EVM and the pivotal role played by a manager in overseeing contract deployment and function execution. It explains the steps involved in updating the state, including contract execution, trade, and different contract types such as deployment, initialization, function, and read calls. It also mentions the implementation of EVM read-only calls to improve efficiency and discusses the flow of minting ERC20 tokens and NFTs on L1X EVM. It highlights the serialization of function calls for EVM compatibility, cross-contract calls using the SDK, and the control flow of event emission in the contract execution process. The approach of having one controller contract and multiple sub-module contracts for efficient processing and data management is also explained.
Section 10. Enhancing Functionality with X-Talk Contract Executor
The discussion elaborates on the X-Talk contract executor's role in facilitating the release of every file and function responsible for activities within the code base. It outlines the process of traversing through the X-Talk, L1x VM and EVM to comprehend the involved files and functions, with the aid of a prepared flowchart aimed at aiding developers in auditing, improving infrastructure, and understanding the codebase. Additionally, considerations regarding the LX VM's potential future role in handling Solidity execution and the current necessity of the EVM, given developers' familiarity with Solidity code, are addressed.
Section 11. Community Questions
Q: Is it possible to phase out L1X EVM and have L1X VM handle Solidity execution?
A: Currently, we have both L1X VM and L1X EVM.
For example, the Neon EVM is designed for Solana, while Aurora serves the NEAR Protocol. If we aim to execute Solidity code on Solana, we would utilize Neon, which operates with its own consensus system, similar to Aurora.
The concern arises when considering the potential scenario where someone builds such functionality on L1X, leading to two distinct infrastructures operating concurrently. As developers increasingly gravitate towards applications requiring X-Talk and Rust Code for contract development, the necessity for EVM diminishes. At present, the EVM remains necessary, but its future necessity is uncertain. Functionality present in L1X EVM is not exclusive; however, its continued adoption is a determining factor. It's important to note that L1X VM isn't inherently tailored for Solidity code but rather Rust Code. Therefore, a decision must be made regarding either adapting the architecture of L1X VM or retaining the current structure until adoption aligns.
Watch this question
Q: How can I get date of birth validated into my Smart Card?
A: Let's break it down into three simple steps:
- Provide Information: You input your date of birth into the smart contract.
- Confirm Information: You verify and confirm that the provided date of birth is correct.
- Retrieve Information: When needed, you retrieve the date of birth.
So, imagine the smart contract has your wallet address linked to your name and date of birth. This information can be stored either on a private database or directly on the L1X infrastructure. When you want to check your date of birth:
- You can create a function off-chain to fetch the date of birth, compare it with your provided information, and then give you a response.
- Alternatively, you can hit a "check" button, which sends your date of birth to the contract. The contract then calculates the time between your birthdate and the current date and gives you a simple yes or no answer. This way, your information is securely stored and only a yes or no response is shared.
Watch this question
Q: Will Testnet be always available to try out our own Smart Contracts?
A: Yes.
There are 3 environments: LocalNet (your computer), DevNet (allows you to simulate the MainNet) and MainNet.
Watch this question
Q: What is the difference between MainNet to DevNet and LocalNet to DevNet?
A: With DevNet, you don't pay for actual L1X Coins.
Between the LocalNet and DevNet, you can test it with multiple Nodes.
Watch this question
Q: How are double-spending and fraud prevented in cross-chain transactions through the VM?
A: In our VMs, we have two main mechanisms for preventing these issues.
Firstly, in stack-based architecture like ours, we utilize an accounts model. This means that when a transaction occurs, it waits regardless of whether the account is in place or not.
Solana uses a Sealevel approach. If your transaction isn't in the queue, they allow it to proceed, meaning your balance isn't affected by other transactions in place.
Secondly, similar to the EVM, we have a clean Mempool structure. Until your transaction receives finality, another transaction can't be processed. However, it's important to consider whether it's just a transfer or a smart contract update for either L1X VM or L1X EVM. These are distinct actions because smart contract activity operates in a different cluster compared to regular transactions.
Solana's approach is experimental and concise, with only about 20 lines of code. However, if something goes wrong, the State Route hash could be damaged, leading to downtime. Despite this, in terms of speed, having different clusters instead of altering the account model seems more logical for Kevin.
Watch this question
Q: Can we extend Bitcoin's capabilities through an L2 solution like Polygon, or is X-Talk exclusive to dApps on L1X, similar to Zeta or Omni dApps?
A: If someone comes and integrates L1X VM, they can utilize X-Talk. The interesting part is that you'll also be able to integrate L1X EVM and still use X-Talk. Essentially, you're constructing an interoperable EVM infrastructure with your own consensus.
Watch this question
Did you miss the L1X Deep Dive Episode I. The State of Interoperability: The Past, the Present and Future? Read the Summary Now.
Did you miss the L1X Deep Dive Episode II. L1X Consensus Mechanism? Read the Summary Now.
Stay updated on Discord and in our Social Media Channels so you don't miss any important News.
Summaries provided are brief overviews of associated YouTube videos. While we aim for accuracy, they may lack full context. For comprehensive understanding, watch the complete videos.
