In this article, we will explore the recently published JAM protocol, examining its approaches and analyzing how it differs from or is similar to the methodologies we intend to employ in the Logos project. We will not delve into the provability aspects of the JAM protocol; instead, we will focus on its underlying concepts and ideas based on the provided resources. It is important to mention that a blog article cannot cover all aspects comprehensively and that not everything can been considered. The aim is merely to provide an overview of the JAM protocol and what it means for the further development in the Logos project.

The Join-Accumulate Machine (JAM) protocol represents a significant advancement in blockchain technology, designed to enhance scalability, efficiency, and security. Drawing inspiration from Polkadot and Ethereum, JAM provides a foundational "framework" for creating highly resilient and flexible decentralized platforms capable of processing a vast number of transactions per second.

JAM utilizes a sophisticated sharding technique that divides the blockchain into smaller, manageable segments called shards (not to be confused with the relay chain/parachain principle; these are different approaches). Each shard operates independently, processing its own data in parallel with other shards. This method significantly enhances overall network throughput and reduces latency. From a technical perspective, each shard functions as an isolated mini-blockchain with its own state and transaction history. This isolation distributes the computational workload across multiple shards, preventing any single shard from becoming a bottleneck and thus ensuring efficient scalability. However, this parallelism introduces complexities in managing cross-shard communication and maintaining consistent state across shards. JAM addresses these challenges with a robust cross-shard communication protocol, Cross-Chain Message Passing (XCMP) that uses advanced cryptographic techniques to ensure data integrity and security while facilitating efficient state synchronization between shards.

An important component of the JAM protocol is the PolkaVM (PVM), an optimized virtual machine designed to execute smart contracts and complex computations securely and efficiently. Simply put, the PolkaVM handles the refine function in the network, which includes the execution of a few off-chain operations and provides "sealed" work reports. The PVM is built to run on the RISC-V architecture, utilizing LLVM (Low-Level Virtual Machine) to compile code into RISC-V instructions. This combination provides a highly optimized execution environment that maximizes efficiency and security. By using RISC-V, the PVM can take advantage of the open and extensible nature of this architecture, ensuring compatibility with a wide range of hardware platforms. One of the PVM's key features is its ability to generate Zero-Knowledge Proofs (zk-Rollups) for the computations it performs (work packages). These proofs allow validators to verify the correctness of off-chain computations without having to execute them themselves, significantly enhancing scalability and efficiency.

Another core feature in JAM is the accumulation function, essential for ensuring the accuracy and efficiency of the data provided by the PVM and the refine function. This process encompasses the collection of work reports, verification of their correctness, and integration into the blockchain. The process begins with the collection of work reports, which are essentially bundles of processed work items. These work report "bundles" undergo a series of verification stages, each applying strict checks to prevent errors and fraud. This includes validating the authenticity of the work reports and ensuring that the computations within them are correct. The final step involves integrating the validated work reports into the blockchain's immutable ledger.

Another key feature, besides the refine and accumulate functions, is the on-transfer function, which handles automated "internal network transactions" ("interaction" between services). This function can change the state of a service by responding to information from other services and plays a crucial role in promoting asynchronous communication and collaboration between the various components of the JAM architecture.

These three functions, Refine, Accumulate, and On-transfer, are considered as service entry points in the JAM protocol.

In JAM Protocol, there are no traditional parachains like those in the relay chain. Instead, there are services, the fundamental units on the JAM chain that include code, balance, and state. Each time an "app-code" is deployed, a new service is automatically created on the chain. The service deployment item contains the code, initial state, and metadata of the new service. Creating a service on the JAM chain is similar to deploying a smart contract on other blockchain platforms. The term “service” in the context of the JAM architecture extends and generalizes the concept of a smart contract as used in traditional blockchain platforms like Ethereum. In platforms like Ethereum, each smart contract is responsible for managing its own state, stored on the blockchain in a distributed ledger. This state is publicly accessible, and changes are triggered by transactions recorded in blocks. In JAM, services can implement more complex state and data management strategies. They can not only access their own data but also efficiently manage interactions and data integrations across different services. This enables more flexible and powerful data storage and processing.

JAM incorporates advanced cryptographic mechanisms and consensus algorithms to protect the network from attacks. Validators in a JAM-based chain play a crucial role by verifying results and ensuring that only valid data is recorded on the blockchain. The consensus mechanisms, including Safrole and Grandpa, help achieve quick finality and maintain the blockchain's integrity. Zero-Knowledge Proofs (ZKPs) and zk-Rollups are employed to enhance privacy, scalability, and verification efficiency, allowing the network to process multiple transactions off-chain and then bundle them into a single proof verified on-chain. Once the PVM generates a zk-Rollup, it is submitted to the validators. The consensus mechanism, particularly Safrole, ensures that these zk-Rollups are correctly verified. This approach also ensures that data can be verified without exposing sensitive information, thus enhancing privacy. Validators, through the consensus process, ensure that these zk-Rollup "report" packages are valid and correctly integrated into the blockchain.

The JAM protocol dynamically manages computational resources, optimizing their use for efficient task execution. By leveraging available resources effectively, a JAM-based chain can swiftly execute operations and smart contracts, reducing operational costs and enhancing network performance. This includes a gas model tailored for modern hardware architectures to ensure continuous and optimal workload distribution. Core Time is referring to a function focused on managing and allocating computational time within the system. Core Time quantifies and limits the execution time a particular process or group of processes consumes on the blockchain. It is a mechanism for managing computational resources, ensuring that no single operation or service disproportionately consumes network resources. Core Time allows specific time windows or resource allocations for different tasks or workloads. By allocating Core Time to specific tasks or services, the system becomes more efficient, reducing overall costs and improving performance by ensuring fair and effective resource utilization.

JAM uses a metered system that evaluates the computational load after execution, reducing the need for frequent benchmarks. However, benchmarks remain relevant in certain scenarios, particularly when metering is deemed too conservative for specific use cases or when tasks require longer execution times. These are just some of the main new aspects that JAM introduces. It is important to note that JAM is still under "review", and changes may occur.

In summary, the JAM protocol introduces innovative approaches to overcome the limitations of traditional blockchain systems. By leveraging sharding, a thorough accumulation process, the PolkaVM, advanced cryptographic measures like ZKPs and zk-Rollups, and sophisticated consensus algorithms, JAM aims to set a new standard for scalability, efficiency, and security in the blockchain space. It is important to understand that JAM is a protocol designed to be implemented within any Substrate-based architecture. As an extension of the existing Substrate framework, JAM can enhance the capabilities of various blockchain platforms, making it a versatile and powerful tool for developers and organizations looking to build resilient, high-performance decentralized solutions.

No Traditional Transactions or Staking
A distinctive feature of the JAM protocol is the absence of traditional transactions and staking mechanisms. Instead of using typical transaction models, JAM relies on an innovative approach where operations and state changes are managed through its accumulation process and advanced consensus algorithms. This eliminates the need for direct transaction fees and staking rewards, simplifying the economic model of the protocol. This approach can reduce overhead and potential security risks associated with staking and traditional transaction fees but requires robust mechanisms to ensure validators are incentivized appropriately and the network remains secure and efficient.

Offchain processing
The PVM performs tasks that do not take place directly on the main blockchain. This includes processing data, executing smart contracts, and possibly other computationally intensive operations that are more efficiently handled off the blockchain. By operating outside the main blockchain, the PVM helps improve the overall system's performance and scalability by preventing the blockchain from being overloaded with complex computations that are more effectively managed in a specialized isolated environment. Despite functioning as an off-chain component, the PVM closely interacts with the on-chain elements of the blockchain. It ensures that results and important data processed off-chain are correctly and securely passed to the validators and then embedded into the blockchain.

ZKP-Proofs
The PVM processes work packages that may contain complex datasets or bundles of operations processed outside the main blockchain. The PVM uses the information from these work packages to create zk-rollups. This involves compiling the results of the work packages into a consolidated state, which is verified by zero-knowledge proofs. These proofs confirm the validity of the operations contained in the work package without having to disclose specific details. These techniques enable efficient, secure, and private processing of transactions on public blockchains, supporting a wide range of applications across various industries and sectors.

Services approach
Services are standalone, modular units in JAM that perform specific tasks within the network. Each service is designed to execute particular functions that contribute to the overall functionality of the system. This leads to the transformation from a large DOT to many smaller DOTs.

Validator Roles and Resource Allocation:
JAM defines specific roles for validators and optimizes resource allocation to ensure efficient network operation.
Based on the analysis from the Gray Paper, JAM targets a total of 1,023 validators (nodes). These validators are distributed with three validators per core, and each validator is expected to perform an average of ten audits per timeslot (6s), leading to 30 audits per work report. In JAM, a "Core" refers to a logical partitioning of computational resources within a node. Each core can be considered an independent unit that performs computations. Audits in JAM refer to the verification of the work performed by the validators. An audit ensures that the computations are accurate and that only trustworthy data is integrated into the blockchain.

Each approach addresses specific challenges in blockchain technology, aiming to enhance scalability, efficiency, and security. However, each approach comes with its own set of challenges and trade-offs that need to be carefully managed to realize the full potential of the JAM protocol. Unique aspects such as the absence of traditional transactions and staking or implementation of services further distinguish JAM, positioning it as a robust and innovative solution in the blockchain space.

For the past two months, we have been conducting research on the topic of Enterprise-Grade Security in Public Blockchain Networks: Handling Private Transactions, Strict Access Control, Key Management, Isolated Execution, Zero-Trust, and Zero-Knowledge Principles. Through the publication of the Gray Paper, we became aware of the JAM protocol. After some preliminary research, we discovered that some specifications resemble our ideas and that we can effectively implement the JAM protocol approaches in the provision of the Logos Chain. We are currently revising our research papers, as we want to incorporate some concepts from the insights gained from the JAM protocol.

From the working title of our research, it can be inferred that the JAM protocol can cover many of the requirements necessary for the Logos Chain. The approach with Zero-Knowledge Proofs (ZKPs) and zk-Rollups creates the possibility to handle private data efficiently and securely on a public blockchain. The refinement and accumulation functions play an important role in handling these processes. Sharding itself does not play a crucial role for the Logos project, but the security it brings does. The execution time on the Logos Chain does not need to be as fast as on the Polkadot-JAM-Chain, as we are aiming for a kind of "accumulated security". The handling through service accounts and the implementation of the on-transfer function bring a high level of security, efficient communication, and automation. The approach of providing services and executing RISC-V compatible code allows us a simpler implementation of the "definitions and operations rules" that were originally intended to be implemented in the form of smart contract logic. These are just some approaches that will help us deliver the specification faster and start the implementation of the Logos Network. It is still unclear whether we will fully implement the JAM protocol or whether a hybrid implementation will take place.

It is important to mention that the Logos Chain, even if it uses the JAM protocol, does not pursue the same goals as the Polkadot-JAM-Chain. Through the JAM protocol, we achieve a resilient, efficient, and automated public blockchain component for the Logos Network. The JAM-Chain aims to provide a platform where theoretically anything that can be compiled in RISC-V can be deployed. The Logos Chain, on the other hand, is intended to be a component that provides a distributed virtual computing infrastructure. On this infrastructure, for example, JAM validators or other blockchain nodes can be deployed to operate these nodes on an underlying core infrastructure, the sub0layer, fully in line with the Web3 ethos. It is also important to mention that the isolated environments provided by the Logos Chain for the blockchain nodes are quasi off-chain but monitored on-chain. This means that the computing operations provided by the Logos Network are not performed on our validators. Since we need to provide and secure a system-level VM, this cannot be done entirely on-chain efficiently. Therefore, a secure environment must be created for this purpose that uses off-chain/on-chain operations, which we intend to do. At some point, it is no longer about creating 100% technological isolation, as we see that a very good isolation for the execution of decentralized applications can be achieved with the PVM. The Logos project aims to create a virtual core infrastructure that is decentralized and whose resources come from community-provided hardware. On this infrastructure, all blockchain nodes, independent of their technology (because system level VM), can then be deployed in an environment secured by the blockchain, thus enabling a fairer and much more Web3-appropriate environment for operating Web3 infrastructure.

How exactly we will implement the JAM protocol will take some time. The Gray Paper is not an easy read and the specifications are not yet fully completed. Currently, it is important for us to publish the research paper that shows the integration of the JAM protocol into our findings as a potential solution. This should help to better understand what we are aiming for in terms of enterprise-grade security in public blockchain networks.

Do you have questions or want to discuss more? Join our discussion on Discord (opens in a new tab)

References:

• Ethereum: A Secure Decentralised Generalised Transaction Ledger - https://ethereum.github.io/yellowpaper/paper.pdf (opens in a new tab)
• From Polkadot to Jam - https://medium.com/@vjgaur/from-polkadot-to-jam-gavin-woods-vision-for-infinitely-scalable-blockchain-infrastructure-e625e29e8b29 (opens in a new tab)
• FAQ for Polkadot's JAM Chain - https://wiki.polkadot.network/docs/learn-jam-faq (opens in a new tab)
• Gavin's Talk about JAM at Token2049 Dubai - https://grillapp.net/@filippoweb3/gavin-s-talk-about-jam-at-token2049-dubai-136004?ref=10124 (opens in a new tab)
• Polkadot 2.0 Roadmap - https://www.opengov.watch/technical_fellowship/polkadot_roadmap (opens in a new tab)
• Join-Accumulate Machine: A Semi-Coherent Scalable Trustless VM - https://graypaper.com (opens in a new tab)
• Polkadot's JAM Chain - https://wiki.polkadot.network/docs/learn-jam-chain (opens in a new tab)
• Polkadot JAM Explained. Simply! https://polkadotters.medium.com/polkadot-jam-explained-simply-825ec8b24607 (opens in a new tab)
• Polkadot: Vision for a heterogeneous multi-chain framework - https://assets.polkadot.network/Polkadot-whitepaper.pdf (opens in a new tab)
• RFC-0031: CoreJam- https://github.com/polkadot-fellows/RFCs/blob/gav-corejam/text/0031-corejam.md (opens in a new tab)
• Zero-knowledge Rollups https://wiki.polkadot.network/docs/learn-comparisons-rollups#zero-knowledge-rollups (opens in a new tab)