Science needs marketing in the same way Nike needs marketing. In this age of mis- and disinformation, a scientist’s job must expand from discovery alone to discovery and persuasion. And that’s where marketing comes in. Science needs marketing in the same way Nike needs marketing.

Why science needs marketing - Bulletin of the Atomic Scientists

Atomic

atomic

The Building Blocks of UI/UX: How Atomic Design Transforms Your Workflow

Author: Artem Chumak, Malware Research Engineer at Moonlock by MacPaw Introduction In our Moonlock Lab, we have been closely monitoring the evolution of the Atomic stealer. This malware has garnered our attention due to its rapid development and the sophisticated features it employs. One particular feature, which we previously highlighted in our X (Twitter) post, stands out for its advanced capability to replace the legitimate LedgerLive app with a malicious clone. In this article, we delve deeper into this feature and its implications. Monitoring and Analysis Our team continuously monitors Darknet forums and Telegram channels used by threat actors. This activity allows us to stay informed about the latest developments and tactics before they spread among users. By infiltrating these channels, we gain real-time insights into the latest updates in cyber threats. One of the great sources of information has been the Telegram channel operated by the group behind the AMOS stealer. This channel not only facilitates the sale of the malware but also provides updates on its development and deployment. By tracking discussions within this channel, we have been able to document the evolution of the Atomic stealer and understand its dynamics. In fact, the operator's regular posts give insights into future developments and tactics, allowing us to anticipate potential changes. Additionally, we learned about the cost of the particular version of Atomic Stealer. One day, while monitoring the Telegram channel of the AMOS operator, we came across an advertisement highlighting a new functionality. This new feature involves replacing the LedgerLive app with a malicious clone without the user noticing. Furthermore, all user actions with the application - such as opening, closing, entering the seed phrase, and sending the seed phrase - are logged into a separate Telegram channel created by the bot for monitoring purposes. This functionality is offered as a unique module designed for regular customers with stable traffic. The module itself is free, but the operators charge a 30% fee for the balance of each seed phrase collected. LedgerLive App's Infection Chain We were particularly interested in and, therefore, obtained and analyzed this version of Atomic Stealer that primarily targets the LedgerLive app. LedgerLive is a widely used application for managing cryptocurrency wallets, providing users with a secure and convenient way to handle their digital assets. Consequently, due to its popularity and the high value of the assets it manages, it has become a lucrative target for cybercriminals. Let’s examine the infection process, which typically begins when a user downloads a malicious installer disguised as CrackInstall.dmg. Inside this seemingly harmless file is the Mach-O stealer, a piece of malware designed to execute silently once opened. Adversaries often provide visual instructions to help victims bypass Gatekeeper. The instructions guide users to right-click on the CrackInstall file and select "Open" to circumvent the security measure. Upon execution, the stealer immediately gets to work, replacing key components in the LedgerLive app. Specifically, it targets files such as App.tsx, PairMyNano.tsx, and ProtectDiscoverBody.tsx, replacing them with malicious versions. This process effectively creates a clone of the original LedgerLive app. The malicious clone is designed to mimic the legitimate app's appearance and functionality, making it difficult for users to detect the compromise. Key Features Phishing for Seed Phrases One critical feature of the infected LedgerLive app is its ability to display a phishing window. This window prompts users to enter their seed phrases, a set of words used to recover cryptocurrency wallets. The app provides a misleading message to create a false sense of security, encouraging users to divulge their sensitive information. Phishing Message: “Your secret phrase is the secret list of words that you backed up when you first set up your wallet. Ledger does not keep a copy of your recovery phrase.” Data Transmission to Command and Control Servers After capturing the seed phrases, the malware deobfuscates the Command and Control (C2) server and transmits the data to  http://159[.]65[.]193[.]64:8080/statistics. This primary server receives the sensitive information, which the attackers can then exploit. Additionally, the malware sends user information and execution status to two other servers: http://77[.]221[.]151[.]29:8080/statistics_v2 and http://77[.]221[.]151[.]29:8080/statistics_v5. This multi-layered approach to data exfiltration ensures that the attackers receive comprehensive information about the infected systems. Conclusion Our analysis of the Atomic Stealer, particularly its ability to target and replace the LedgerLive app, has revealed its advanced capabilities. The LedgerLive clone mimics the real app, making it difficult for users to detect the compromise. By logging all user interactions, the attackers can capture sensitive information, such as seed phrases, which are crucial for accessing cryptocurrency wallets. To protect yourself, always download software from official sources, avoid clicking on suspicious links, and use robust security tools like CleanMyMac X with Moonlock Engine to detect and block such threats. IoCs Diff of infected and original LedgerLive app: GitHub Gist 304145c8c242644a7aa866383bdac3c169f944ea8c6656b663c223da1359fbb9

SHA256

DMGCrackInstall



0822cf5c34341d124164b1c89889dedc405034e40fd0c8a219859a2561a289ee

SHA256

Mach-O



5c9e197c4e7752e6a15fc9077fa41dc78ac5a737ae73a01ddb6b6fc6aadd1f1c

SHA256

Malicious LedgerLive App Component App.tsx



8c23db010886261cb27a5fbaa45502586f4031cc60bda3a8df778d94a3335888

SHA256

Malicious LedgerLive App ComponentPairMyNano.tsx



9d5bcbdc139561951256a43cc05dda3e18da99ffd200975bbf0732e90a97c710

SHA256

Malicious LedgerLive App ComponentProtectDiscoverBody.tsx



1e86fd2688e7d0086e243194504318c125a5a7c8a1ef6f42bf39bd90deba793b

SHA256

Malicious LedgerLive App Componentapp.asar Author: Artem Chumak, Malware Research Engineer at Moonlock by MacPaw Author: Introduction In our Moonlock Lab , we have been closely monitoring the evolution of the Atomic stealer. This malware has garnered our attention due to its rapid development and the sophisticated features it employs. One particular feature, which we previously highlighted in our X (Twitter) post , stands out for its advanced capability to replace the legitimate LedgerLive app with a malicious clone. In this article, we delve deeper into this feature and its implications. Moonlock Lab Moonlock Lab X (Twitter) post X (Twitter) post Monitoring and Analysis Our team continuously monitors Darknet forums and Telegram channels used by threat actors. This activity allows us to stay informed about the latest developments and tactics before they spread among users. By infiltrating these channels, we gain real-time insights into the latest updates in cyber threats. One of the great sources of information has been the Telegram channel operated by the group behind the AMOS stealer. This channel not only facilitates the sale of the malware but also provides updates on its development and deployment. By tracking discussions within this channel, we have been able to document the evolution of the Atomic stealer and understand its dynamics. malware malware Atomic stealer Atomic stealer In fact, the operator's regular posts give insights into future developments and tactics, allowing us to anticipate potential changes. Additionally, we learned about the cost of the particular version of Atomic Stealer. One day, while monitoring the Telegram channel of the AMOS operator, we came across an advertisement highlighting a new functionality. This new feature involves replacing the LedgerLive app with a malicious clone without the user noticing. Furthermore, all user actions with the application - such as opening, closing, entering the seed phrase, and sending the seed phrase - are logged into a separate Telegram channel created by the bot for monitoring purposes. This functionality is offered as a unique module designed for regular customers with stable traffic. The module itself is free, but the operators charge a 30% fee for the balance of each seed phrase collected. LedgerLive App's Infection Chain We were particularly interested in and, therefore, obtained and analyzed this version of Atomic Stealer that primarily targets the LedgerLive app. LedgerLive is a widely used application for managing cryptocurrency wallets, providing users with a secure and convenient way to handle their digital assets. Consequently, due to its popularity and the high value of the assets it manages, it has become a lucrative target for cybercriminals. Let’s examine the infection process, which typically begins when a user downloads a malicious installer disguised as CrackInstall.dmg. Inside this seemingly harmless file is the Mach-O stealer, a piece of malware designed to execute silently once opened. Adversaries often provide visual instructions to help victims bypass Gatekeeper. The instructions guide users to right-click on the CrackInstall file and select "Open" to circumvent the security measure. Upon execution, the stealer immediately gets to work, replacing key components in the LedgerLive app. Specifically, it targets files such as App.tsx, PairMyNano.tsx, and ProtectDiscoverBody.tsx, replacing them with malicious versions. This process effectively creates a clone of the original LedgerLive app. The malicious clone is designed to mimic the legitimate app's appearance and functionality, making it difficult for users to detect the compromise. Key Features Phishing for Seed Phrases One critical feature of the infected LedgerLive app is its ability to display a phishing window. This window prompts users to enter their seed phrases, a set of words used to recover cryptocurrency wallets. The app provides a misleading message to create a false sense of security, encouraging users to divulge their sensitive information. Phishing Message: “Your secret phrase is the secret list of words that you backed up when you first set up your wallet. Ledger does not keep a copy of your recovery phrase.” Data Transmission to Command and Control Servers After capturing the seed phrases, the malware deobfuscates the Command and Control (C2) server and transmits the data to  http://159[.]65[.]193[.]64:8080/statistics. This primary server receives the sensitive information, which the attackers can then exploit. Additionally, the malware sends user information and execution status to two other servers: http://77[.]221[.]151[.]29:8080/statistics_v2 and http://77[.]221[.]151[.]29:8080/statistics_v5. This multi-layered approach to data exfiltration ensures that the attackers receive comprehensive information about the infected systems. Conclusion Our analysis of the Atomic Stealer, particularly its ability to target and replace the LedgerLive app, has revealed its advanced capabilities. The LedgerLive clone mimics the real app, making it difficult for users to detect the compromise. By logging all user interactions, the attackers can capture sensitive information, such as seed phrases, which are crucial for accessing cryptocurrency wallets. To protect yourself, always download software from official sources, avoid clicking on suspicious links, and use robust security tools like CleanMyMac X with Moonlock Engine to detect and block such threats. Moonlock Engine IoCs Diff of infected and original LedgerLive app: GitHub Gist GitHub Gist GitHub Gist 304145c8c242644a7aa866383bdac3c169f944ea8c6656b663c223da1359fbb9

SHA256

DMGCrackInstall



0822cf5c34341d124164b1c89889dedc405034e40fd0c8a219859a2561a289ee

SHA256

Mach-O



5c9e197c4e7752e6a15fc9077fa41dc78ac5a737ae73a01ddb6b6fc6aadd1f1c

SHA256

Malicious LedgerLive App Component App.tsx



8c23db010886261cb27a5fbaa45502586f4031cc60bda3a8df778d94a3335888

SHA256

Malicious LedgerLive App ComponentPairMyNano.tsx



9d5bcbdc139561951256a43cc05dda3e18da99ffd200975bbf0732e90a97c710

SHA256

Malicious LedgerLive App ComponentProtectDiscoverBody.tsx



1e86fd2688e7d0086e243194504318c125a5a7c8a1ef6f42bf39bd90deba793b

SHA256

Malicious LedgerLive App Componentapp.asar 304145c8c242644a7aa866383bdac3c169f944ea8c6656b663c223da1359fbb9

SHA256

DMGCrackInstall 0822cf5c34341d124164b1c89889dedc405034e40fd0c8a219859a2561a289ee

SHA256

Mach-O 5c9e197c4e7752e6a15fc9077fa41dc78ac5a737ae73a01ddb6b6fc6aadd1f1c

SHA256

Malicious LedgerLive App Component App.tsx 8c23db010886261cb27a5fbaa45502586f4031cc60bda3a8df778d94a3335888

SHA256

Malicious LedgerLive App ComponentPairMyNano.tsx 9d5bcbdc139561951256a43cc05dda3e18da99ffd200975bbf0732e90a97c710

SHA256

Malicious LedgerLive App ComponentProtectDiscoverBody.tsx 1e86fd2688e7d0086e243194504318c125a5a7c8a1ef6f42bf39bd90deba793b

SHA256

Malicious LedgerLive App Componentapp.asar 304145c8c242644a7aa866383bdac3c169f944ea8c6656b663c223da1359fbb9 SHA256 DMGCrackInstall 304145c8c242644a7aa866383bdac3c169f944ea8c6656b663c223da1359fbb9 304145c8c242644a7aa866383bdac3c169f944ea8c6656b663c223da1359fbb9 SHA256 SHA256 DMGCrackInstall DMGCrackInstall 0822cf5c34341d124164b1c89889dedc405034e40fd0c8a219859a2561a289ee SHA256 Mach-O 0822cf5c34341d124164b1c89889dedc405034e40fd0c8a219859a2561a289ee 0822cf5c34341d124164b1c89889dedc405034e40fd0c8a219859a2561a289ee SHA256 SHA256 Mach-O Mach-O 5c9e197c4e7752e6a15fc9077fa41dc78ac5a737ae73a01ddb6b6fc6aadd1f1c SHA256 Malicious LedgerLive App Component App.tsx 5c9e197c4e7752e6a15fc9077fa41dc78ac5a737ae73a01ddb6b6fc6aadd1f1c 5c9e197c4e7752e6a15fc9077fa41dc78ac5a737ae73a01ddb6b6fc6aadd1f1c SHA256 SHA256 Malicious LedgerLive App Component App.tsx Malicious LedgerLive App Component App.tsx 8c23db010886261cb27a5fbaa45502586f4031cc60bda3a8df778d94a3335888 SHA256 Malicious LedgerLive App ComponentPairMyNano.tsx 8c23db010886261cb27a5fbaa45502586f4031cc60bda3a8df778d94a3335888 8c23db010886261cb27a5fbaa45502586f4031cc60bda3a8df778d94a3335888 SHA256 SHA256 Malicious LedgerLive App ComponentPairMyNano.tsx Malicious LedgerLive App ComponentPairMyNano.tsx 9d5bcbdc139561951256a43cc05dda3e18da99ffd200975bbf0732e90a97c710 SHA256 Malicious LedgerLive App ComponentProtectDiscoverBody.tsx 9d5bcbdc139561951256a43cc05dda3e18da99ffd200975bbf0732e90a97c710 9d5bcbdc139561951256a43cc05dda3e18da99ffd200975bbf0732e90a97c710 SHA256 SHA256 Malicious LedgerLive App ComponentProtectDiscoverBody.tsx Malicious LedgerLive App ComponentProtectDiscoverBody.tsx 1e86fd2688e7d0086e243194504318c125a5a7c8a1ef6f42bf39bd90deba793b SHA256 Malicious LedgerLive App Componentapp.asar 1e86fd2688e7d0086e243194504318c125a5a7c8a1ef6f42bf39bd90deba793b 1e86fd2688e7d0086e243194504318c125a5a7c8a1ef6f42bf39bd90deba793b SHA256 SHA256 Malicious LedgerLive App Componentapp.asar Malicious LedgerLive App Componentapp.asar

Tracking Atomic Stealer on macOS: Sophisticated Malware Replacing LedgerLive App

ম্যাকওএস-এ পারমাণবিক চুরির ট্র্যাকিং: লেজারলাইভ অ্যাপ প্রতিস্থাপনকারী অত্যাধুনিক ম্যালওয়্যার

Atomic Stealer auf macOS verfolgen: Ausgefeilte Malware ersetzt LedgerLive-App

Seguimiento de Atomic Stealer en macOS: malware sofisticado que reemplaza la aplicación LedgerLive

Suivi d'Atomic Stealer sur macOS : un malware sophistiqué remplace l'application LedgerLive

मैकओएस पर एटॉमिक स्टीलर को ट्रैक करना: लेजरलाइव ऐप की जगह ले रहा परिष्कृत मैलवेयर

macOS 上の Atomic Stealer を追跡: LedgerLive アプリを置き換える高度なマルウェア

macOS에서 Atomic Stealer 추적: LedgerLive 앱을 대체하는 정교한 맬웨어

Rastreando o Atomic Stealer no macOS: malware sofisticado substituindo o aplicativo LedgerLive

Отслеживание Atomic Stealer на macOS: сложная вредоносная программа, заменяющая приложение LedgerLive

macOS'ta Atomic Stealer'ı Takip Etme: LedgerLive Uygulamasını Değiştiren Karmaşık Kötü Amaçlı Yazılım

Theo dõi Atomic Stealer trên macOS: Phần mềm độc hại tinh vi thay thế ứng dụng LedgerLive

追踪 macOS 上的原子窃取程序：复杂的恶意软件正在取代 LedgerLive 应用程序

In a relational database, a transaction is a series of operations that must be executed in a way that guarantees ACID properties: Atomicity, Consistency, Isolation, and Durability. Atomicity, the ‘A’ in ACID, ensures that all operations within a transaction are completed; otherwise, none of them are. This guarantees that the system’s state remains consistent even in the face of failures. In monolithic systems, achieving atomicity is straightforward since all operations happen within a single database. However, in microservices and distributed environments, achieving atomicity becomes challenging as transactions span multiple services and databases. Distributed Transactions In a distributed system, a single transaction often involves multiple microservices, each with its own database. Ensuring atomicity in such an environment requires coordination across these services. Distributed transactions are managed using two primary protocols: Two-Phase Commit (2PC): A coordination protocol that ensures all participants in a transaction agree to commit or roll back the transaction. Saga Pattern: A sequence of local transactions where each service updates its data and publishes an event or invokes another service. Two-Phase Commit (2PC) This protocol involves a coordinator who manages the transaction’s commit process in two phases: prepare and commit. In the preparation phase, the coordinator asks all participants if they can commit. If all participants agree, the commit phase begins, and the coordinator instructs them to commit the transaction. If any participant cannot commit, the coordinator instructs all participants to roll back. Pros: Guarantees atomicity and consistency. Cons: Can be slow due to the need for coordination.
Prone to blocking if participants fail to respond. Saga Pattern Instead of a single global transaction, the saga pattern breaks the transaction into multiple smaller transactions, each handled by a different service. If any step fails, compensating transactions are executed to undo the changes made by previous steps. Pros: More scalable and resilient to failures.
Non-blocking. Cons: More complex to implement due to the need for compensating transactions.
Potential for temporary inconsistencies. Challenges and Solutions Network Partitions: Network failures can cause communication issues between services, leading to incomplete transactions. Solutions include implementing retry mechanisms and using distributed consensus algorithms like Paxos or Raft. Data Consistency: Maintaining data consistency across services is challenging. Eventual consistency models and using conflict resolution strategies can help mitigate this issue. Performance Overheads: Distributed transactions can introduce significant performance overheads. Using asynchronous processing and optimizing transaction boundaries can help improve performance. Check out my personal blog for more updated posts. In a relational database, a transaction is a series of operations that must be executed in a way that guarantees ACID properties: Atomicity, Consistency, Isolation, and Durability. Atomicity, the ‘A’ in ACID, ensures that all operations within a transaction are completed; otherwise, none of them are. This guarantees that the system’s state remains consistent even in the face of failures. In monolithic systems, achieving atomicity is straightforward since all operations happen within a single database. However, in microservices and distributed environments, achieving atomicity becomes challenging as transactions span multiple services and databases. Distributed Transactions In a distributed system, a single transaction often involves multiple microservices, each with its own database. Ensuring atomicity in such an environment requires coordination across these services. Distributed transactions are managed using two primary protocols: Two-Phase Commit (2PC): A coordination protocol that ensures all participants in a transaction agree to commit or roll back the transaction. Two-Phase Commit (2PC): Saga Pattern: A sequence of local transactions where each service updates its data and publishes an event or invokes another service. Saga Pattern: Two-Phase Commit (2PC) This protocol involves a coordinator who manages the transaction’s commit process in two phases: prepare and commit. In the preparation phase, the coordinator asks all participants if they can commit. If all participants agree, the commit phase begins, and the coordinator instructs them to commit the transaction. If any participant cannot commit, the coordinator instructs all participants to roll back. Pros: Pros: Guarantees atomicity and consistency. Guarantees atomicity and consistency. Cons: Cons: Can be slow due to the need for coordination. Prone to blocking if participants fail to respond. Can be slow due to the need for coordination. Prone to blocking if participants fail to respond. Saga Pattern Instead of a single global transaction, the saga pattern breaks the transaction into multiple smaller transactions, each handled by a different service. If any step fails, compensating transactions are executed to undo the changes made by previous steps. Pros: Pros: More scalable and resilient to failures. Non-blocking. More scalable and resilient to failures. Non-blocking. Cons: Cons: More complex to implement due to the need for compensating transactions. Potential for temporary inconsistencies. More complex to implement due to the need for compensating transactions. Potential for temporary inconsistencies. Challenges and Solutions Network Partitions: Network failures can cause communication issues between services, leading to incomplete transactions. Solutions include implementing retry mechanisms and using distributed consensus algorithms like Paxos or Raft. Network Partitions: Data Consistency: Maintaining data consistency across services is challenging. Eventual consistency models and using conflict resolution strategies can help mitigate this issue. Data Consistency: Performance Overheads: Distributed transactions can introduce significant performance overheads. Using asynchronous processing and optimizing transaction boundaries can help improve performance. Performance Overheads: Check out my personal blog for more updated posts. personal blog

Ensuring Atomicity in Distributed Systems: Managing Transactions Across Microservices

This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction
Formal Model - Rollups with Decentralized Common Pool (DCP)
Atomic composability & ZK-proofs
Incorporating Zk-proofs
Application of the Formal Model
Conclusion and References 4 Incorporating Zk-proofs To integrate zk-proofs into the model effectively, it would require the rollups participating in this system to be zk-proof compatible. They should be able to generate and verify these proofs efficiently. Furthermore, standardization of proofs related to atomic composability would be necessary to ensure smooth inter-rollup operations [4]. 1. Verification Functions: Introduce verification functions within the model that use zkproofs. These functions can quickly validate the correctness and completion of dependent transactions without needing full transparency into the transactions [2]. 2. Reduced Buffering Requirement: With zk-proofs validating transaction dependencies almost immediately, the need for extensive buffering can be reduced. Transactions can be executed swiftly after their zk-proof verifications succeed [3]. 3. Privacy Maintenance: As zk-proofs can validate statements without revealing the underlying data, transactions across rollups can maintain higher degrees of privacy, even in interdependent scenarios [1]. 4. Slashing with zk-proofs: The monitoring and reporting mechanism can also utilize zkproofs. Watchers can provide a zk-proof of misbehavior, which if validated, can lead to punitive measures [12]. 5. Proofs of Dependency Resolution: In the case of cyclic or complex dependencies, zkproofs can be crafted to ensure that all necessary conditions across rollups have been met without revealing the specifics of the transactions involved [6]. The integration of zk-proofs does introduce added cryptographic complexity, but with the advantages of swift validation, reduced need for buffering, and enhanced privacy, they can significantly bolster the robustness and efficiency of the atomic composability model across rollups [13]. This paper is available on arxiv under CC 4.0 license. Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name This paper is available on arxiv under CC 4.0 license. Authors: Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Incorporating Zk-proofs Application of the Formal Model Conclusion and References Abstract and Introduction Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Atomic composability & ZK-proofs Incorporating Zk-proofs Incorporating Zk-proofs Application of the Formal Model Application of the Formal Model Conclusion and References Conclusion and References 4 Incorporating Zk-proofs To integrate zk-proofs into the model effectively, it would require the rollups participating in this system to be zk-proof compatible. They should be able to generate and verify these proofs efficiently. Furthermore, standardization of proofs related to atomic composability would be necessary to ensure smooth inter-rollup operations [4]. 1. Verification Functions: Introduce verification functions within the model that use zkproofs. These functions can quickly validate the correctness and completion of dependent transactions without needing full transparency into the transactions [2]. 2. Reduced Buffering Requirement: With zk-proofs validating transaction dependencies almost immediately, the need for extensive buffering can be reduced. Transactions can be executed swiftly after their zk-proof verifications succeed [3]. 3. Privacy Maintenance: As zk-proofs can validate statements without revealing the underlying data, transactions across rollups can maintain higher degrees of privacy, even in interdependent scenarios [1]. 4. Slashing with zk-proofs: The monitoring and reporting mechanism can also utilize zkproofs. Watchers can provide a zk-proof of misbehavior, which if validated, can lead to punitive measures [12]. 5. Proofs of Dependency Resolution: In the case of cyclic or complex dependencies, zkproofs can be crafted to ensure that all necessary conditions across rollups have been met without revealing the specifics of the transactions involved [6]. The integration of zk-proofs does introduce added cryptographic complexity, but with the advantages of swift validation, reduced need for buffering, and enhanced privacy, they can significantly bolster the robustness and efficiency of the atomic composability model across rollups [13].

Towards Universal Atomic Composability:  Incorporating Zk-proofs

This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction
Formal Model - Rollups with Decentralized Common Pool (DCP)
Atomic composability & ZK-proofs
Incorporating Zk-proofs
Application of the Formal Model
Conclusion and References 5 Application of the Formal Model As the Ethereum ecosystem evolves, diverse scaling solutions have emerged to address the challenges of throughput and latency. Among them, the concept of shared sequencers has gained significant traction. Shared sequencers act as centralized transaction ordering mechanisms, increasing throughput by temporarily assuming the role of transaction orderer before these transactions are batched and finalized on the main chain. While they introduce efficiencies, shared sequencers inherently operate differently from typical rollups, warranting an exploration of how our formal model for atomic composability can be applied to them. The application of our formal model to shared sequencers and other existing solutions accentuates its versatility and universality. Whether it’s the centralized nature of sequencers or the diverse architectures of other rollups, the principles of atomic composability, as proposed in our model, remain consistent. This consistency is instrumental in creating a cohesive, interoperable, and scalable Ethereum ecosystem that can cater to the ever-growing demands of decentralized applications and services. In this section, we extend our formal model to understand its implications on shared sequencers and juxtapose it with other prevailing solutions in the space. The goal is to provide a comparative analysis that not only elucidates the strengths and potential drawbacks of each approach but also offers a cohesive understanding of how atomic composability can be universally achieved irrespective of the underlying scaling solution. 5.1 Shared Sequencers Shared sequencers, by design, centralize the transaction ordering mechanism without compromising the security guarantees of the main chain. Transactions are quickly processed off chain by the sequencer and then aggregated into larger batches to be submitted on-chain. This architecture provides the dual benefit of swift transaction times and reduced on-chain congestion. 5.1.1 Implications of the Formal Model: 1. Buffering & Dependency Handling: Given that shared sequencers operate in an off-chain environment before finalization, the buffering mechanism we proposed becomes even more critical. It allows for the temporary storage of transactions, especially when there are cross-rollup or cross-sequencer dependencies. 2. Concurrency Control: Shared sequencers inherently deal with a high volume of simultaneous transactions. Implementing our concurrency control mechanism ensures that interdependent transactions, even from different sources or rollups, can be processed in an atomic fashion. 3. Zero-Knowledge Proofs & Validation: The validation mechanism using zk-proofs becomes an asset here. It ensures that even in a semi-centralized environment, transaction validations remain private, swift, and secure. The zk-proofs also provide an added layer of trust to users who might be skeptical of the centralized nature of sequencers. 5.2 Alternative solutions: While shared sequencers present a compelling case for scalability, other solutions like zk-rollups, optimistic rollups, and sidechains each have their unique architectures and merits. 1. zk-Rollups: These rely heavily on zk-proofs for batched transaction validation. Applying our formal model, zk-rollups can benefit from enhanced dependency handling and buffering mechanisms, ensuring transactions across rollups are consistently processed. 2. Optimistic Rollups: Here, transactions are assumed to be correct until proven otherwise. Our formal model introduces a systematic approach for handling disputes and reordering, ensuring atomic composability without extensive delays. 3. Sidechains: Being independent blockchains, sidechains can pose more significant challenges for atomic composability. Our model can act as a bridge, providing mechanisms like dependency resolution and buffering to ensure smooth inter-chain operations. This paper is available on arxiv under CC 4.0 license. Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name This paper is available on arxiv under CC 4.0 license. Authors: Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Incorporating Zk-proofs Application of the Formal Model Conclusion and References Abstract and Introduction Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Atomic composability & ZK-proofs Incorporating Zk-proofs Incorporating Zk-proofs Application of the Formal Model Application of the Formal Model Conclusion and References Conclusion and References 5 Application of the Formal Model As the Ethereum ecosystem evolves, diverse scaling solutions have emerged to address the challenges of throughput and latency. Among them, the concept of shared sequencers has gained significant traction. Shared sequencers act as centralized transaction ordering mechanisms, increasing throughput by temporarily assuming the role of transaction orderer before these transactions are batched and finalized on the main chain. While they introduce efficiencies, shared sequencers inherently operate differently from typical rollups, warranting an exploration of how our formal model for atomic composability can be applied to them. The application of our formal model to shared sequencers and other existing solutions accentuates its versatility and universality. Whether it’s the centralized nature of sequencers or the diverse architectures of other rollups, the principles of atomic composability, as proposed in our model, remain consistent. This consistency is instrumental in creating a cohesive, interoperable, and scalable Ethereum ecosystem that can cater to the ever-growing demands of decentralized applications and services. In this section, we extend our formal model to understand its implications on shared sequencers and juxtapose it with other prevailing solutions in the space. The goal is to provide a comparative analysis that not only elucidates the strengths and potential drawbacks of each approach but also offers a cohesive understanding of how atomic composability can be universally achieved irrespective of the underlying scaling solution. 5.1 Shared Sequencers 5.1 Shared Sequencers Shared sequencers, by design, centralize the transaction ordering mechanism without compromising the security guarantees of the main chain. Transactions are quickly processed off chain by the sequencer and then aggregated into larger batches to be submitted on-chain. This architecture provides the dual benefit of swift transaction times and reduced on-chain congestion. 5.1.1 Implications of the Formal Model: 5.1.1 Implications of the Formal Model: 1. Buffering & Dependency Handling: Given that shared sequencers operate in an off-chain environment before finalization, the buffering mechanism we proposed becomes even more critical. It allows for the temporary storage of transactions, especially when there are cross-rollup or cross-sequencer dependencies. 2. Concurrency Control: Shared sequencers inherently deal with a high volume of simultaneous transactions. Implementing our concurrency control mechanism ensures that interdependent transactions, even from different sources or rollups, can be processed in an atomic fashion. 3. Zero-Knowledge Proofs & Validation: The validation mechanism using zk-proofs becomes an asset here. It ensures that even in a semi-centralized environment, transaction validations remain private, swift, and secure. The zk-proofs also provide an added layer of trust to users who might be skeptical of the centralized nature of sequencers. 5.2 Alternative solutions: 5.2 Alternative solutions: While shared sequencers present a compelling case for scalability, other solutions like zk-rollups, optimistic rollups, and sidechains each have their unique architectures and merits. 1. zk-Rollups: These rely heavily on zk-proofs for batched transaction validation. Applying our formal model, zk-rollups can benefit from enhanced dependency handling and buffering mechanisms, ensuring transactions across rollups are consistently processed. 2. Optimistic Rollups: Here, transactions are assumed to be correct until proven otherwise. Our formal model introduces a systematic approach for handling disputes and reordering, ensuring atomic composability without extensive delays. 3. Sidechains: Being independent blockchains, sidechains can pose more significant challenges for atomic composability. Our model can act as a bridge, providing mechanisms like dependency resolution and buffering to ensure smooth inter-chain operations.

Towards Universal Atomic Composability: Application of the Formal Model

This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction
Formal Model - Rollups with Decentralized Common Pool (DCP)
Atomic composability & ZK-proofs
Incorporating Zk-proofs
Application of the Formal Model
Conclusion and References 2 Formal Model - Rollups with Decentralized Common Pool (DCP) Addressing the multifaceted nature of blockchain ecosystems, especially those spanning several rollups, demands a structured, rigorous approach to uphold transactional integrity and reliability. To this end, our formal model seeks to methodically dissect and elucidate atomic composability across Ethereum’s multiple rollups. Our model is an amalgamation of classic distributed system theories and innovative cryptographic practices. We recognize that merely adapting traditional system theories to the blockchain milieu is not sufficient, necessitating a model tailored for the peculiarities of decentralized ledgers, especially within Ethereum’s ecosystem ([9]. Subsequent sections will delve into the intricacies of our formal model, commencing with fundamental definitions. We will then probe into operational dynamics, examining transactional workflows, dependency resolutions, and concurrency nuances. Cryptographic methodologies, particularly zeroknowledge proofs, will be highlighted, underscoring their pivotal role in efficient, confidential transaction validations. With this formal model, our aspiration is to furnish readers with an encompassing, lucid, and rigorous comprehension of how to establish, sustain, and, if necessary, re-establish atomic composability in environments with multiple rollups. 2.1 Definitions • R: Set of rollups on Ethereum. • T: Set of transactions, where Ti,j is the j-th transaction on rollup Ri. • Pd: Decentralized common pool. • K: Set of cryptographic keys associated with transactions. • τ : Timestamp attached to each transaction when it’s accepted by the majority of Pd nodes. • B: Buffer zone where transactions with pending dependencies are stored. • τmax: Maximum time a transaction can reside in buffer B. • Bmax: Maximum number of transactions that can reside in buffer B. • Dmax: Maximum number of attempts to resolve a transaction’s dependencies. 2.2 Operations 2.2.1 Publish • Description: This operation ensures that every transaction Ti,j from rollup Ri is published to the Decentralized Common Pool Pd. • Steps: 1. Ri generates a transaction Ti,j . 2. Ri sends Ti,j to Pd. 3. On receiving Ti,j , the majority of nodes in Pd timestamp it with τ and store it. • Output: publish(Ti,j ) → Pd(τ ) 2.2.2 Buffer • Description: Transactions with unmet dependencies are sent to the buffer B until their dependencies are resolved or they hit one of the defined limits. • Steps: 1. If Ti,j has unresolved dependencies, it’s directed to B. 2. Ti,j resides in B until either its dependencies are resolved or it breaches one of the constraints (τmax, Bmax, or Dmax). • Output: buffer(Ti,j ) → B 2.2.3 Resolve • Description: The operation checks for and resolves dependencies between two transactions, possibly from different rollups. • Steps: 1. Given two transactions Ti,j and Tk,l, Pd checks for their mutual dependencies. 2. If dependencies exist, Pd attempts resolution based on available data and timestamps. 3. If resolution is successful within the constraints, the transactions proceed. Otherwise, they remain in B or are rejected. • Output: resolve(Ti,j , Tk,l) → bool 2.2.4 Verify • Description: Ensures the validity and authenticity of the transaction using cryptographic keys. • Steps: 1. For each transaction Ti,j , Pd uses the associated cryptographic key Ki,j to verify its authenticity and integrity. 2. If the verification succeeds, the transaction proceeds. Otherwise, it’s deemed invalid. • Output: verify(Ti,j , Ki,j ) → bool 2.3 Transaction Processing For two transactions Ti,j from Ri and Tk,l from Rk: 2.3.1 Timestamp-Based Handling If both transactions are timestamped in Pd and their timestamps are within an acceptable time difference (delta): Then, the transactions are deemed compatible and can be processed without buffering. 2.3.2 Buffering • If the timestamp difference exceeds the acceptable delta, or if there’s a dependency which isn’t yet satisfied, transactions are sent to B. • While in B: – Periodic checks are done to see if dependencies can now be resolved. – If (τcurrent − τ (Ti,j )) > τmax, Ti,j is rejected. – If the buffer size exceeds Bmax, a rejection policy PR is triggered to create space. – If attempts to resolve dependencies for Ti,j exceed Dmax, Ti,j is rejected. 2.3.3 Rejection and Notification Once a transaction is rejected, a notification mechanism informs the originating rollup Ri or the respective party about the rejection. This allows for potential re-submission or other actions from the user’s end. 2.4 Rollup Punitive Measures 2.4.1 Staking Mechanism Every rollup must stake a certain number of tokens to participate in the transaction composability system. This stake acts as collateral that can be forfeited or slashed if the rollup misbehaves. 2.4.2 Monitoring and Reporting Third-party nodes or participants (often called "watchers" or "validators") can monitor transactions and execution behaviors across rollups. If they detect a rollup executing a transaction without proper validation or not adhering to the model’s rules, they can submit a proof of this misbehavior. 2.4.3 Misbehavior Proof A system can be put in place to accept proofs of misbehavior. Once verified, punitive measures can be enacted on the misbehaving rollup, including forfeiting their staked tokens. 2.5 Decentralized Common Pool (DCP) Instead of having a centralized common pool, we can utilize a decentralized common pool, Pd. This pool would be maintained and updated by a network of nodes, ensuring redundancy and security. Utilizing a consensus mechanism, these nodes can agree on the state of the pool. 2.5.1 Core features • Consensus Mechanism: Nodes in the Pd network use a consensus mechanism (like PoS, PoA, or a Byzantine Fault Tolerance mechanism) to validate and agree on the state of the pool. This prevents any single entity from maliciously modifying the data. • Data Redundancy: The decentralized nature ensures that multiple copies of the transaction pool are stored across nodes. This redundancy makes it resistant to single points of failure and data tampering. • Cryptographic Verification: Apart from using cryptographic keys for transaction verification, node participation, data propagation, and pool updates in the Pd network are also secured using cryptographic techniques, ensuring data integrity and authenticity. 2.5.2 Concurrency Handling with Transaction Delay/Rejection • Timestamping: Each transaction that’s published to Pd is timestamped. This timestamp is based on when the transaction is received by the majority of nodes in the Pd network. • Transaction Buffer: Transactions that have dependencies across rollups are not immediately processed. Instead, they’re placed in a buffer zone. • Dependency Resolution with Buffer: During the resolution phase, the system checks the buffer to resolve dependencies. If Transaction Ti,j depends on Transaction Tk,l, the system will: – Check if both transactions are in the buffer and if their timestamps are within an acceptable time difference (delta). – If they are, the system processes both transactions. – If not, and if the dependency can’t be resolved within a certain timeframe, the system might either: 1. Reject one or both of the transactions. 2. Delay the transaction processing until the dependency is resolved or a timeout occurs. 2.5.3 Challenges With the incorporation of a decentralized common pool, timestamping, a transaction buffer for dependency resolution, and enhanced security measures, the solution addresses many of the concurrency and security concerns. However, it’s essential to consider trade-offs: • The system might have increased complexity due to decentralization and consensus mechanisms. • Transaction delays, while managing concurrency, might not be suitable for applications that require real-time processing. • Ensuring all nodes in the Pd network are updated in near real-time might present scalability challenges. This paper is available on arxiv under CC 4.0 license. Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name This paper is available on arxiv under CC 4.0 license. Authors: Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Incorporating Zk-proofs Application of the Formal Model Conclusion and References Abstract and Introduction Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Atomic composability & ZK-proofs Incorporating Zk-proofs Incorporating Zk-proofs Application of the Formal Model Application of the Formal Model Conclusion and References Conclusion and References 2 Formal Model - Rollups with Decentralized Common Pool (DCP) Addressing the multifaceted nature of blockchain ecosystems, especially those spanning several rollups, demands a structured, rigorous approach to uphold transactional integrity and reliability. To this end, our formal model seeks to methodically dissect and elucidate atomic composability across Ethereum’s multiple rollups. Our model is an amalgamation of classic distributed system theories and innovative cryptographic practices. We recognize that merely adapting traditional system theories to the blockchain milieu is not sufficient, necessitating a model tailored for the peculiarities of decentralized ledgers, especially within Ethereum’s ecosystem ([9]. Subsequent sections will delve into the intricacies of our formal model, commencing with fundamental definitions. We will then probe into operational dynamics, examining transactional workflows, dependency resolutions, and concurrency nuances. Cryptographic methodologies, particularly zeroknowledge proofs, will be highlighted, underscoring their pivotal role in efficient, confidential transaction validations. With this formal model, our aspiration is to furnish readers with an encompassing, lucid, and rigorous comprehension of how to establish, sustain, and, if necessary, re-establish atomic composability in environments with multiple rollups. 2.1 Definitions 2.1 Definitions • R: Set of rollups on Ethereum. • T: Set of transactions, where Ti,j is the j-th transaction on rollup Ri. • Pd: Decentralized common pool. • K: Set of cryptographic keys associated with transactions. • τ : Timestamp attached to each transaction when it’s accepted by the majority of Pd nodes. • B: Buffer zone where transactions with pending dependencies are stored. • τmax: Maximum time a transaction can reside in buffer B. • Bmax: Maximum number of transactions that can reside in buffer B. • Dmax: Maximum number of attempts to resolve a transaction’s dependencies. 2.2 Operations 2.2 Operations 2.2.1 Publish 2.2.1 Publish • Description: This operation ensures that every transaction Ti,j from rollup Ri is published to the Decentralized Common Pool Pd. • Steps: • Steps: 1. Ri generates a transaction Ti,j . 2. Ri sends Ti,j to Pd. 3. On receiving Ti,j , the majority of nodes in Pd timestamp it with τ and store it. • Output: publish(Ti,j ) → Pd(τ ) 2.2.2 Buffer 2.2.2 Buffer • Description: Transactions with unmet dependencies are sent to the buffer B until their Description: dependencies are resolved or they hit one of the defined limits. • Steps: • Steps: 1. If Ti,j has unresolved dependencies, it’s directed to B. 2. Ti,j resides in B until either its dependencies are resolved or it breaches one of the constraints (τmax, Bmax, or Dmax). • Output: buffer(Ti,j ) → B 2.2.3 Resolve 2.2.3 Resolve • Description: The operation checks for and resolves dependencies between two transactions, possibly from different rollups. • Description: • Steps: • Steps: 1. Given two transactions Ti,j and Tk,l, Pd checks for their mutual dependencies. 2. If dependencies exist, Pd attempts resolution based on available data and timestamps. 3. If resolution is successful within the constraints, the transactions proceed. Otherwise, they remain in B or are rejected. • Output: resolve(Ti,j , Tk,l) → bool • Output: 2.2.4 Verify 2.2.4 Verify • Description: Ensures the validity and authenticity of the transaction using cryptographic • Description: keys. • Steps: • Steps: 1. For each transaction Ti,j , Pd uses the associated cryptographic key Ki,j to verify its authenticity and integrity. 2. If the verification succeeds, the transaction proceeds. Otherwise, it’s deemed invalid. • Output: verify(Ti,j , Ki,j ) → bool • Output: 2.3 Transaction Processing 2.3 Transaction Processing For two transactions Ti,j from Ri and Tk,l from Rk: 2.3.1 Timestamp-Based Handling 2.3.1 Timestamp-Based Handling If both transactions are timestamped in Pd and their timestamps are within an acceptable time difference (delta): Then, the transactions are deemed compatible and can be processed without buffering. 2.3.2 Buffering 2.3.2 Buffering • If the timestamp difference exceeds the acceptable delta, or if there’s a dependency which isn’t yet satisfied, transactions are sent to B. • While in B: – Periodic checks are done to see if dependencies can now be resolved. – If (τcurrent − τ (Ti,j )) > τmax, Ti,j is rejected. – If the buffer size exceeds Bmax, a rejection policy PR is triggered to create space. – If attempts to resolve dependencies for Ti,j exceed Dmax, Ti,j is rejected. 2.3.3 Rejection and Notification 2.3.3 Rejection and Notification Once a transaction is rejected, a notification mechanism informs the originating rollup Ri or the respective party about the rejection. This allows for potential re-submission or other actions from the user’s end. 2.4 Rollup Punitive Measures 2.4 Rollup Punitive Measures 2.4.1 Staking Mechanism 2.4.1 Staking Mechanism Every rollup must stake a certain number of tokens to participate in the transaction composability system. This stake acts as collateral that can be forfeited or slashed if the rollup misbehaves. 2.4.2 Monitoring and Reporting 2.4.2 Monitoring and Reporting Third-party nodes or participants (often called "watchers" or "validators") can monitor transactions and execution behaviors across rollups. If they detect a rollup executing a transaction without proper validation or not adhering to the model’s rules, they can submit a proof of this misbehavior. 2.4.3 Misbehavior Proof 2.4.3 Misbehavior Proof A system can be put in place to accept proofs of misbehavior. Once verified, punitive measures can be enacted on the misbehaving rollup, including forfeiting their staked tokens. 2.5 Decentralized Common Pool (DCP) 2.5 Decentralized Common Pool (DCP) Instead of having a centralized common pool, we can utilize a decentralized common pool, Pd. This pool would be maintained and updated by a network of nodes, ensuring redundancy and security. Utilizing a consensus mechanism, these nodes can agree on the state of the pool. 2.5.1 Core features 2.5.1 Core features • Consensus Mechanism: Nodes in the Pd network use a consensus mechanism (like PoS, PoA, or a Byzantine Fault Tolerance mechanism) to validate and agree on the state of the pool. This prevents any single entity from maliciously modifying the data. • Data Redundancy: The decentralized nature ensures that multiple copies of the transaction pool are stored across nodes. This redundancy makes it resistant to single points of failure and data tampering. • Cryptographic Verification: Apart from using cryptographic keys for transaction verification, node participation, data propagation, and pool updates in the Pd network are also secured using cryptographic techniques, ensuring data integrity and authenticity. 2.5.2 Concurrency Handling with Transaction Delay/Rejection 2.5.2 Concurrency Handling with Transaction Delay/Rejection • Timestamping: Each transaction that’s published to Pd is timestamped. This timestamp is based on when the transaction is received by the majority of nodes in the Pd network. • Transaction Buffer: Transactions that have dependencies across rollups are not immediately processed. Instead, they’re placed in a buffer zone. • Dependency Resolution with Buffer: During the resolution phase, the system checks the buffer to resolve dependencies. If Transaction Ti,j depends on Transaction Tk,l, the system will: – Check if both transactions are in the buffer and if their timestamps are within an acceptable time difference (delta). – If they are, the system processes both transactions. – If not, and if the dependency can’t be resolved within a certain timeframe, the system might either: 1. Reject one or both of the transactions. 2. Delay the transaction processing until the dependency is resolved or a timeout occurs. 2.5.3 Challenges 2.5.3 Challenges With the incorporation of a decentralized common pool, timestamping, a transaction buffer for dependency resolution, and enhanced security measures, the solution addresses many of the concurrency and security concerns. However, it’s essential to consider trade-offs: • The system might have increased complexity due to decentralization and consensus mechanisms. • Transaction delays, while managing concurrency, might not be suitable for applications that require real-time processing. • Ensuring all nodes in the Pd network are updated in near real-time might present scalability challenges.

Towards Universal Atomic Composability: Formal Model - Rollups with Decentralized Common Pool (DCP)

This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction
Formal Model - Rollups with Decentralized Common Pool (DCP)
Atomic composability & ZK-proofs
Incorporating Zk-proofs
Application of the Formal Model
Conclusion and References 3 Atomic composability & ZK-proofs Zero-Knowledge Proofs (zk-proofs), particularly zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and zk-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge), are cryptographic methods that allow one party to prove to another party that a statement is true, without revealing any specific information beyond the validity of the statement itself [1, 2]. For atomic composability across rollups, zk-proofs can be exceptionally beneficial. Let’s explore how: 3.1 Transaction Validation zk-proofs can be utilized to validate that a transaction on one rollup adheres to specific conditions, without actually revealing the contents of the transaction. This is especially useful for maintaining privacy across rollups while still ensuring that conditions are met [6]. 3.2 Dependency Verification If one transaction depends on another from a different rollup, zk-proofs can be utilized to validate the successful execution and correctness of the dependent transaction, again, without revealing the actual transaction details [7]. 3.3 Concurrency and Aggregate Dependencies zk-proofs can be crafted to provide proofs of concurrent transaction executions or aggregate transaction conditions (like total transaction value across multiple rollups) being met, all without revealing specific transaction details [12]. 3.4 Compactness and Efficiency zk-proofs, especially zk-SNARKs, have the advantage of being succinct. That means, irrespective of the amount of data or the number of transactions they’re validating, the proof size remains relatively small and verification is swift. This feature can be immensely beneficial in a system with multiple rollups, where swift validations are essential [10]. This paper is available on arxiv under CC 4.0 license. Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name This paper is available on arxiv under CC 4.0 license. Authors: Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Incorporating Zk-proofs Application of the Formal Model Conclusion and References Abstract and Introduction Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Atomic composability & ZK-proofs Incorporating Zk-proofs Incorporating Zk-proofs Application of the Formal Model Application of the Formal Model Conclusion and References Conclusion and References 3 Atomic composability & ZK-proofs Zero-Knowledge Proofs (zk-proofs), particularly zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and zk-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge), are cryptographic methods that allow one party to prove to another party that a statement is true, without revealing any specific information beyond the validity of the statement itself [1, 2]. For atomic composability across rollups, zk-proofs can be exceptionally beneficial. Let’s explore how: 3.1 Transaction Validation 3.1 Transaction Validation zk-proofs can be utilized to validate that a transaction on one rollup adheres to specific conditions, without actually revealing the contents of the transaction. This is especially useful for maintaining privacy across rollups while still ensuring that conditions are met [6]. 3.2 Dependency Verification 3.2 Dependency Verification If one transaction depends on another from a different rollup, zk-proofs can be utilized to validate the successful execution and correctness of the dependent transaction, again, without revealing the actual transaction details [7]. 3.3 Concurrency and Aggregate Dependencies 3.3 Concurrency and Aggregate Dependencies zk-proofs can be crafted to provide proofs of concurrent transaction executions or aggregate transaction conditions (like total transaction value across multiple rollups) being met, all without revealing specific transaction details [12]. 3.4 Compactness and Efficiency 3.4 Compactness and Efficiency zk-proofs, especially zk-SNARKs, have the advantage of being succinct. That means, irrespective of the amount of data or the number of transactions they’re validating, the proof size remains relatively small and verification is swift. This feature can be immensely beneficial in a system with multiple rollups, where swift validations are essential [10].

Towards Universal Atomic Composability: Atomic composability & ZK-proofs

This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction
Formal Model - Rollups with Decentralized Common Pool (DCP)
Atomic composability & ZK-proofs
Incorporating Zk-proofs
Application of the Formal Model
Conclusion and References 6 Conclusion The formal model presented serves as a superset for all possible atomic composability across rollups because of its comprehensive nature. This model is a superset because it is designed to encompass every step, every entity, and every possible scenario in the lifecycle of a transaction across rollups. By being exhaustive in its approach, any atomic composability solution across rollups that exists or might be conceived in the future can be mapped onto some subset of this model. It acts as a general framework or blueprint from which specific implementations can be derived, tailored to particular requirements or constraints. Comprehensiveness of Definitions It identifies every rollup, transaction, timestamp, cryptographic key, buffer mechanism, and even the decentralized pool where transactions are posted. This covers all essential tools and entities required for atomic transactions between rollups. Detailed Operations The detailed operation steps ensure that every conceivable action associated with transactions – from their creation, publication, verification, buffering, to dependency resolution – is incorporated: • Publish: Every transaction is committed to a decentralized common pool, capturing the universal broadcast mechanism. • Buffer: Handles the uncertainties and delays. • Resolve: Manages interdependencies, making sure that if one transaction in a set can’t be executed, none in that set are. • Verify: Ensures that only legitimate and valid transactions are processed. Robust Dependency Handling This is perhaps the crux of atomic composability. The model provides: • A method to check the timing (timestamps) of transactions, which is crucial for ensuring order and dependencies. • Buffering mechanisms to account for delays in dependency resolution. • Defined limits for buffering to prevent infinite waits and to give an outcome (acceptance or rejection) within a finite time. Flexibility & Scalability The model doesn’t restrict the number or type of dependencies. It simply provides mechanisms to handle them. This ensures that as blockchain technology evolves and new dependency types emerge or transactions become more intricate, the model remains applicable. Incorporation of Limits By integrating system limits like τmax, Bmax, and Dmax, the model not only accounts for ideal scenarios where all dependencies are quickly resolved but also for edge cases where system constraints come into play. This adds to its universality. Security through Verification The model’s inclusion of cryptographic verification ensures that security concerns are front and center. It recognizes that composability isn’t just about making sure transactions work together, but that they’re also genuine and untampered. References [1] E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer, and M. Virza. Snarks for c: Verifying program executions succinctly and in zero knowledge. In Proceedings of the 33rd Annual Cryptology Conference, pages 90–108. Springer, 2013. [2] E. Ben-Sasson, I. Bentov, Y. Horesh, and M. Riabzev. Scalable, transparent, and post-quantum secure computational integrity. IACR Cryptol. ePrint Arch., 2018:46, 2018. [3] N. Bitansky, R. Canetti, A. Chiesa, and E. Tromer. Extractable collision resistance: A new complexity assumption for zero-knowledge. Advances in Cryptology–CRYPTO 2012, pages 416–434, 2012. [4] V. Buterin. A next-generation smart contract and decentralized application platform. White paper, 2014. Available at https://ethereum.org/en/whitepaper/. [5] V. Buterin. Ethereum’s scalability and decentralization challenge, 2020. [6] R. Gennaro, C. Gentry, B. Parno, and M. Raykova. Quadratic span programs and succinct nizks without pcps. In Proceedings of the 32nd Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 626–645. Springer, 2013. [7] S. Micali. Cs proofs. Journal of Cryptology, 4(3):175–194, 1994. [8] S. Micali. Atomic transactions in blockchain, 2016. [9] A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder. Bitcoin and Cryptocurrency Technologies. Princeton University Press, 2016. [10] C. Reitwiessner. zk-snarks in a nutshell. Blog post, 2016. Available at https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/. [11] F. Schär. Decentralized finance: On blockchain- and smart contract-based financial markets. Federal Reserve Bank of St. Louis Review, 2020. [12] R. S. Wahby, I. Tzialla, A. Shelat, J. Thaler, and M. Walfish. Fast and simple constant-size zk-snarks without trusted setup. IACR Cryptol. ePrint Arch., 2019:748, 2019. [13] H. Williamson. Optimistic rollups: Layer 2 scaling. Blog post, 2020. Available at https://optimism.io/. This paper is available on arxiv under CC 4.0 license. Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name This paper is available on arxiv under CC 4.0 license. Authors: Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Incorporating Zk-proofs Application of the Formal Model Conclusion and References Abstract and Introduction Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Atomic composability & ZK-proofs Incorporating Zk-proofs Incorporating Zk-proofs Application of the Formal Model Application of the Formal Model Conclusion and References Conclusion and References 6 Conclusion The formal model presented serves as a superset for all possible atomic composability across rollups because of its comprehensive nature. This model is a superset because it is designed to encompass every step, every entity, and every possible scenario in the lifecycle of a transaction across rollups. By being exhaustive in its approach, any atomic composability solution across rollups that exists or might be conceived in the future can be mapped onto some subset of this model. It acts as a general framework or blueprint from which specific implementations can be derived, tailored to particular requirements or constraints. Comprehensiveness of Definitions It identifies every rollup, transaction, timestamp, cryptographic key, buffer mechanism, and even the decentralized pool where transactions are posted. This covers all essential tools and entities required for atomic transactions between rollups. Comprehensiveness of Definitions Detailed Operations The detailed operation steps ensure that every conceivable action associated with transactions – from their creation, publication, verification, buffering, to dependency resolution – is incorporated: Detailed Operations • Publish: Every transaction is committed to a decentralized common pool, capturing the universal broadcast mechanism. • Buffer: Handles the uncertainties and delays. • Resolve: Manages interdependencies, making sure that if one transaction in a set can’t be executed, none in that set are. • Verify: Ensures that only legitimate and valid transactions are processed. Robust Dependency Handling This is perhaps the crux of atomic composability. The model provides: • A method to check the timing (timestamps) of transactions, which is crucial for ensuring order and dependencies. • Buffering mechanisms to account for delays in dependency resolution. • Defined limits for buffering to prevent infinite waits and to give an outcome (acceptance or rejection) within a finite time. Flexibility & Scalability The model doesn’t restrict the number or type of dependencies. It simply provides mechanisms to handle them. This ensures that as blockchain technology evolves and new dependency types emerge or transactions become more intricate, the model remains applicable. Incorporation of Limits By integrating system limits like τmax, Bmax, and Dmax, the model not only accounts for ideal scenarios where all dependencies are quickly resolved but also for edge cases where system constraints come into play. This adds to its universality. Security through Verification The model’s inclusion of cryptographic verification ensures that security concerns are front and center. It recognizes that composability isn’t just about making sure transactions work together, but that they’re also genuine and untampered. References [1] E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer, and M. Virza. Snarks for c: Verifying program executions succinctly and in zero knowledge. In Proceedings of the 33rd Annual Cryptology Conference, pages 90–108. Springer, 2013. [2] E. Ben-Sasson, I. Bentov, Y. Horesh, and M. Riabzev. Scalable, transparent, and post-quantum secure computational integrity. IACR Cryptol. ePrint Arch., 2018:46, 2018. [3] N. Bitansky, R. Canetti, A. Chiesa, and E. Tromer. Extractable collision resistance: A new complexity assumption for zero-knowledge. Advances in Cryptology–CRYPTO 2012, pages 416–434, 2012. [4] V. Buterin. A next-generation smart contract and decentralized application platform. White paper, 2014. Available at https://ethereum.org/en/whitepaper/. [5] V. Buterin. Ethereum’s scalability and decentralization challenge, 2020. [6] R. Gennaro, C. Gentry, B. Parno, and M. Raykova. Quadratic span programs and succinct nizks without pcps. In Proceedings of the 32nd Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 626–645. Springer, 2013. [7] S. Micali. Cs proofs. Journal of Cryptology, 4(3):175–194, 1994. [8] S. Micali. Atomic transactions in blockchain, 2016. [9] A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder. Bitcoin and Cryptocurrency Technologies. Princeton University Press, 2016. [10] C. Reitwiessner. zk-snarks in a nutshell. Blog post, 2016. Available at https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/. [11] F. Schär. Decentralized finance: On blockchain- and smart contract-based financial markets. Federal Reserve Bank of St. Louis Review, 2020. [12] R. S. Wahby, I. Tzialla, A. Shelat, J. Thaler, and M. Walfish. Fast and simple constant-size zk-snarks without trusted setup. IACR Cryptol. ePrint Arch., 2019:748, 2019. [13] H. Williamson. Optimistic rollups: Layer 2 scaling. Blog post, 2020. Available at https://optimism.io/.

Towards Universal Atomic Composability: Conclusion and References

This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction
Formal Model - Rollups with Decentralized Common Pool (DCP)
Atomic composability & ZK-proofs
Incorporating Zk-proofs
Application of the Formal Model
Conclusion and References Abstract In the rapidly evolving domain of distributed ledger technology, scalability and interoperability have become paramount challenges for both academic and industry sectors. In this paper, we introduce a comprehensive formal model to address atomic composability across multiple rollups on Ethereum. The proposed model incorporates mechanisms like buffering, dependency management, concurrency control, and the groundbreaking zero-knowledge proofs. Moreover, we evaluate its practical repercussions, strengths, and weaknesses, ensuring resilience against manipulative or erroneous actions. The application of the proposed model to shared sequencers and other existing solutions accentuates its versatility and universality. 1 Introduction In the rapidly evolving domain of distributed ledger technology, scalability and interoperability have become paramount challenges for both academic and industry sectors. Ethereum, recognized as a pioneering smart contract platform, has initiated a myriad of advancements, with rollups being a significant answer to the blockchain trilemma: balancing scalability, security, and decentralization [5]. However, as rollups appear promising for scalability, they might unintentionally lead to fragmented composability. Given the intertwining nature of systems and applications, ensuring atomicity in transactions across systems is vital. Atomic composability is predicated on the principle that a transaction (A) can only be finalized if another transaction (B) is likewise finalized [8]. For decentralized applications that operate over multiple rollups, this assurance is critical. Yet, actualizing this atomicity with disconnected rollups on Ethereum presents major obstacles. This paper offers a thorough formal model that addresses atomic composability across multiple rollups on Ethereum. Incorporating insights from established distributed system solutions and contemporary cryptographic methodologies, the proposed model encompasses buffering, dependency management, concurrency control, and the groundbreaking zero-knowledge proofs [1]. Beyond proposing the model, we evaluate its practical repercussions, strengths, and weaknesses, ensuring resilience against manipulative or erroneous actions. Our intent extends beyond presenting a solution; we seek to stimulate a wider discourse on the future trajectory of interconnected blockchains. With a surge in applications shifting to a multi-rollup framework on Ethereum and elsewhere, a robust system guaranteeing atomic composability becomes indispensable. Through our model and ensuing discussions, we aim to make substantial contributions to this burgeoning field of blockchain study. 1.1 What are Rollups? Rollups, in the Ethereum context, are scaling mechanisms that bolster network throughput. They operate by conducting transactions off-chain and subsequently submitting a transaction summary to the primary Ethereum chain, thus enhancing transaction capacity without overloading the main Ethereum network [5]. 1.2 What is Composability? Within blockchain and Ethereum paradigms, composability pertains to the capability of decentralized applications (dApps) and smart contracts to effortlessly integrate and leverage one another’s features [11]. This can be analogized to “money Legos”, where each protocol or dApp represents an individual Lego piece, capable of diverse combinations. 1.3 Limits of Composability Between Rollups With the deployment of multiple rollups on Ethereum, challenges arise in ensuring seamless interaction of dApps and contracts across these rollups. This dilemma is intensified if rollups operate in isolation or lack an effective bridging mechanism. Atomic Transactions Across Rollups: Ensuring atomic composability between rollups necessitates that a transaction in one rollup is only finalized if its counterpart in another rollup is as well. This is intricate because each rollup might possess unique consensus algorithms, validation methodologies, and operational latency. Data Availability: For a contract in one rollup to interface with data or another contract on a distinct rollup, the requisite data from the latter may not be readily accessible or may be costly to retrieve. Differing Rules and Standards: Distinct rollups with divergent standards or rules regarding transaction processing can further impede cross-rollup interactions. This paper is available on arxiv under CC 4.0 license. Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name This paper is available on arxiv under CC 4.0 license. Authors: Authors: (1) Dipankar Sarkar, Cryptuon Research and me@dipankar.name Table of Links Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Incorporating Zk-proofs Application of the Formal Model Conclusion and References Abstract and Introduction Abstract and Introduction Formal Model - Rollups with Decentralized Common Pool (DCP) Formal Model - Rollups with Decentralized Common Pool (DCP) Atomic composability & ZK-proofs Atomic composability & ZK-proofs Incorporating Zk-proofs Incorporating Zk-proofs Application of the Formal Model Application of the Formal Model Conclusion and References Conclusion and References Abstract In the rapidly evolving domain of distributed ledger technology, scalability and interoperability have become paramount challenges for both academic and industry sectors. In this paper, we introduce a comprehensive formal model to address atomic composability across multiple rollups on Ethereum. The proposed model incorporates mechanisms like buffering, dependency management, concurrency control, and the groundbreaking zero-knowledge proofs. Moreover, we evaluate its practical repercussions, strengths, and weaknesses, ensuring resilience against manipulative or erroneous actions. The application of the proposed model to shared sequencers and other existing solutions accentuates its versatility and universality. 1 Introduction In the rapidly evolving domain of distributed ledger technology, scalability and interoperability have become paramount challenges for both academic and industry sectors. Ethereum, recognized as a pioneering smart contract platform, has initiated a myriad of advancements, with rollups being a significant answer to the blockchain trilemma: balancing scalability, security, and decentralization [5]. However, as rollups appear promising for scalability, they might unintentionally lead to fragmented composability. Given the intertwining nature of systems and applications, ensuring atomicity in transactions across systems is vital. Atomic composability is predicated on the principle that a transaction (A) can only be finalized if another transaction (B) is likewise finalized [8]. For decentralized applications that operate over multiple rollups, this assurance is critical. Yet, actualizing this atomicity with disconnected rollups on Ethereum presents major obstacles. This paper offers a thorough formal model that addresses atomic composability across multiple rollups on Ethereum. Incorporating insights from established distributed system solutions and contemporary cryptographic methodologies, the proposed model encompasses buffering, dependency management, concurrency control, and the groundbreaking zero-knowledge proofs [1]. Beyond proposing the model, we evaluate its practical repercussions, strengths, and weaknesses, ensuring resilience against manipulative or erroneous actions. Our intent extends beyond presenting a solution; we seek to stimulate a wider discourse on the future trajectory of interconnected blockchains. With a surge in applications shifting to a multi-rollup framework on Ethereum and elsewhere, a robust system guaranteeing atomic composability becomes indispensable. Through our model and ensuing discussions, we aim to make substantial contributions to this burgeoning field of blockchain study. 1.1 What are Rollups? 1.1 What are Rollups? Rollups, in the Ethereum context, are scaling mechanisms that bolster network throughput. They operate by conducting transactions off-chain and subsequently submitting a transaction summary to the primary Ethereum chain, thus enhancing transaction capacity without overloading the main Ethereum network [5]. 1.2 What is Composability? 1.2 What is Composability? Within blockchain and Ethereum paradigms, composability pertains to the capability of decentralized applications (dApps) and smart contracts to effortlessly integrate and leverage one another’s features [11]. This can be analogized to “money Legos”, where each protocol or dApp represents an individual Lego piece, capable of diverse combinations. 1.3 Limits of Composability Between Rollups 1.3 Limits of Composability Between Rollups With the deployment of multiple rollups on Ethereum, challenges arise in ensuring seamless interaction of dApps and contracts across these rollups. This dilemma is intensified if rollups operate in isolation or lack an effective bridging mechanism. Atomic Transactions Across Rollups: Ensuring atomic composability between rollups necessitates that a transaction in one rollup is only finalized if its counterpart in another rollup is as well. This is intricate because each rollup might possess unique consensus algorithms, validation methodologies, and operational latency. Atomic Transactions Across Rollups: Data Availability: For a contract in one rollup to interface with data or another contract on a distinct rollup, the requisite data from the latter may not be readily accessible or may be costly to retrieve. Data Availability: Differing Rules and Standards: Distinct rollups with divergent standards or rules regarding transaction processing can further impede cross-rollup interactions. Differing Rules and Standards:

Stories, News & Mentions about ATOMIC

Atomic’s Stories on HackerNoon

Atomic's News & Mentions