What if you had the chance to put yourself out of business?\n\nImagine you could work on the next once-in-a-decade innovation that redefines an entire creative industry

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:

Towards Universal Atomic Composability: Abstract and Introduction

Design Systems: A Front-End Engineer's Guide to Efficient Atomic Design

Hey there, coffee in hand? Great! Let’s roll up our sleeves and get ready for a thrilling dive into the world of transactions! Now, what’s on the menu for this electrifying journey, you ask? Here are the main acts of the show: Definition of The Transaction and ACID Properties Real-World Scenarios: Implementing DbContextTransaction in Entity Framework Definition of The Transaction and ACID Properties : Imagine you’re a big fan of Apple like me, and you are bankrupt, yet determined to acquire the coveted Apple Watch Ultra 2. In such a scenario, you’d initiate a new entry in the database dedicated to Apple watch buyers. This action exemplifies a transaction, an operation performed within the database. Now, picture this: As you’re meticulously inputting your purchase details for the Apple Ultra Watch 2, you commence payment using two different methods due to your financial situation. However, just as you’re processing the second payment, an unexpected case occurs. What unfolds in such a predicament? Well, here’s where the concept of Atomicity comes into play. When I refer to “atomicity,” I mean that the transaction must occur in an all-or-nothing fashion. Either both payments are successfully processed, or none of them are. This concept is a vital component of the quartet of : tomicity, onsistency, solation, and urability, collectively ensuring the integrity and precision of the database. fundamental transaction properties A C I D As on the , ACID is an acronym that refers to the set of 4 key properties that define a transaction: and If a database operation has these ACID properties, it can be called an ACID transaction, and data storage systems that apply these operations are called transactional systems. You can more about this concept in the mentioned Databricks website Atomicity, Consistency, Isolation, Durability. find MongoDB article. Real-World Scenarios: Implementing DbContextTransaction in .Net and Entity Framework Let’s engage in the hypothetical scenario once more! Imagine you have a system with a specific requirement: you need to , and these transactions must capture essential details in the database. These details include the purchase ID, customer name, timestamp, date, payments made via Visa, payments made in cash, and the product name. document the purchase transactions that happened in your store after payments are done from the user side To fulfill this requirement, you’ve established a structured database schema, ensuring that the system operates seamlessly and maintains data integrity. Now, how did you guarantee that the system accurately associates payments, whether made via Visa or in cash, with their respective purchases? Furthermore, how you will ensure that if any issues arise, none of these payments will be processed/documented in the database without a corresponding purchase record in the system? Well, we can achieve this using which is a class in Entity Framework that represents a transaction within the database context. It allows you to group multiple database operations into a single transaction, ensuring that they are all either committed together or rolled back together if an error occurs. DbContextTransaction private void DocumentPurchases(object sender, EventArgs e)
{

    // Start a new database transaction using the CashDbEntities DbContext
    using (DbContextTransaction transaction = StoriedParameter.CashDbEntities.Database.BeginTransaction())
    {
        try
        {
            // Create a new Purchase object and populate its properties
            Purchase newPurchase = new Purchase
            {
                PurchaseID = PurchaseID, // Set the PurchaseID property
                CustomerID = customerId, // Set the CustomerID property
                // Create a new DateTime object based on purchaseTime, with specified year, month, day, hour, minute, and second
                PurchaseTime = new DateTime(purchaseTime.GetTime.Year, purchaseTime.GetTime.Month, purchaseTime.GetTime.Day, purchaseTime.GetTime.Hour, purchaseTime.GetTime.Minute, purchaseTime.GetTime.Second),
                PurchaseDate = purchaseDate.SelectedDate, // Set the PurchaseDate property
                ProductName = productName.Text, // Set the ProductName property
                // Parse the visaAmount.Text to a float it's not empty otherwise set it to 0
                VisaPaymentAmount = string.IsNullOrEmpty(visaAmount.Text) ? 0 : float.Parse(visaAmount.Text),
                // Parse the cashAmount.Text to a float it's not empty otherwise set it to 0
                CashPaymentAmount = string.IsNullOrEmpty(cashAmount.Text) ? 0 : float.Parse(cashAmount.Text)
            };

            // Add the newPurchase to the Purchases DbSet 
            CashDbEntities.Purchases.Add(newPurchase);

            // Check if there is a visa payment amount greater than 0
            if (float.Parse(visaAmount.Text) > 0)
            {
                // Create a new VisaPayment object and populate its properties
                VisaPayment newVisaPayment = new VisaPayment
                {
                    PurchaseID = newPurchase.PurchaseID, // Set the PurchaseID property
                    VisaCardNumber = float.Parse(visaCardNumber.Text), // Parse the visaCardNumber.Text to a float
                    // Set VisaPaymentDetails to null if visaPaymentDetails.Text is empty, otherwise set it to the text value
                    VisaPaymentDetails = string.IsNullOrEmpty(visaPaymentDetails.Text) ? null : visaPaymentDetails.Text
                };

                // Add the newVisaPayment to the VisaPayments DbSet
                CashDbEntities.VisaPayments.Add(newVisaPayment);
            }

            // Check if there is a cash payment amount greater than 0
            if (float.Parse(cashAmount.Text) > 0)
            {
                // Create a new CashPayment object and populate its properties
                CashPayment newCashPayment = new CashPayment
                {
                    PurchaseID = newPurchase.PurchaseID, // Set the PurchaseID property
                    // Set CashPaymentDetails to null if cashPaymentDetails.Text is empty, otherwise set it to the text value
                    CashPaymentDetails = string.IsNullOrEmpty(cashPaymentDetails.Text) ? null : cashPaymentDetails.Text
                };

                // Add the newCashPayment to the CashPayments DbSet
                CashDbEntities.CashPayments.Add(newCashPayment);
            }

            // Save changes to the database
            CashDbEntities.SaveChanges();

            // Commit the database transaction
            transaction.Commit();
        }
        catch (Exception ex)
        {
            // Rollback the transaction if an exception occurs
            transaction.Rollback();
            // Display an error message with the exception's message to the console
            Console.WriteLine("An error occurred: " + ex.Message);
        }
    }

} In short words, these lines of code initialize a database transaction using Entity Framework. Any database operations that follow within the the block will be part of this transaction, and if an exception occurs or when the block is exited, the transaction will be either committed or rolled back automatically, ensuring data integrity in the database. using Note that some fields are validated while others are not. I’ve created a separate function that checks the essential fields when the user triggers the “Save Purchase” button. The required fields for validation include , , , , , , , , and . The remaining fields are optional, allowing us to include data even if they are empty. PurchaseID VisaCardNumber CashPaymentAmount VisaPaymentAmount ProductName PurchaseDate PurchaseTime CustomerID PurchaseID It’s as simple as that, A piece of cake! See you in the next articles. Stay tuned, just like when you stay tuned for Apple products ;) Resources https://learn.microsoft.com/en-us/dotnet/api/system.data.entity.dbcontext?view=entity-framework-6.2.0 https://datascientest.com/en/acid-in-database-management https://www.databricks.com/glossary/acid-transactions

Exploring Atomicity with DbContextTransaction in .NET and Entity Framework

The Noonification: The Double-Edged Sword of Atomic Design (5/11/2023)

The complexity of modern websites has grown significantly over the past few years. The increased demand for high-quality, industry-standard designs further intensifies the challenges faced by frontend developers. Today, even frontend apps need some architectural considerations to streamline the development process. In my , I shared my experience implementing the clean architecture approach in front-end applications while working on my . previous article side project In this article, I aim to delve deeper into the atomic design approach, drawing from my experiences with the same project. I will discuss its advantages and disadvantages, and evaluate its usefulness in different scenarios. Background on design systems To begin, let's explore the concept of a design system. are comprehensive collections of reusable components, guidelines, and principles that empower teams to design and develop consistent user interfaces across multiple platforms. Design systems They act as a single source of truth for both designers and developers, ensuring that the visual and functional aspects of a product align and adhere to the established brand identity. If you're interested in exploring examples of design system implementations, consider examining the following: Carbon design system Grommet design system If you want to dive deeper into the topic of design systems I recommend checking out . It describes this topic in detail, details that are not required for us in the scope of this work. this article How atomic design is derived from design systems Building on the foundation of design systems, atomic design is a methodology that streamlines the organization and structuring of reusable components and guidelines. Conceived by is inspired by chemistry, as it deconstructs user interfaces into their most fundamental building blocks and reassembles them into more intricate structures. Brad Frost, Atomic Design Here's an image illustrating the analogy to chemistry: Chemical reactions are represented by chemical equations, which often show how atomic elements combine together to form molecules. In the example above, we see how hydrogen and oxygen combine together to form water molecules. In essence, atomic design is a natural evolution of design systems, providing a systematic approach to creating flexible and scalable components. By applying the principles of atomic design, teams can manage their design systems more efficiently, as the modular nature of this methodology makes it easier to maintain, update, and extend the components and patterns within the system. If you're concerned that this may sound complex, don't worry. In the upcoming sections, I'll demonstrate how to apply these principles using a real-life example from the app I've developed, making it easy to understand and implement in your own projects. Overview of atomic design The atomic design organizes components into five distinct levels, each building upon the previous. Let's explore these five levels in detail: : the most basic building blocks of a user interface, atoms represent individual HTML elements such as buttons, input fields, and headings. They are the smallest functional units and cannot be broken down further. atoms : molecules are formed by combining two or more atoms into a functional group. For instance, a search form molecule might consist of a search input atom, a button atom, and a label atom. Molecules represent simple components that can be reused across a project. molecules : organisms are more complex components, created by combining multiple molecules and/or atoms. They represent distinct sections of a user interface, such as a header, footer, or sidebar. Organisms help to form the overall layout and structure of a page. organisms : templates are essentially page layouts built using organisms, molecules, and atoms. They define the structure and arrangement of components on a page without specifying any actual content, serving as a blueprint for various content scenarios. templates : pages are the final, fully realized instances of templates, complete with real content and data. They represent what users will ultimately see and interact with, showcasing how the components and layout adapt to different content types and use cases. pages The NotionLingo app: a case study In order to develop a well-informed perspective on atomic design for frontend development, I embarked on a journey to create an application. Over a period of six months, I gained valuable insights and experience while working on this project. Consequently, the examples provided throughout this article draw from my hands-on experience with the application. To maintain transparency, all examples are derived from publicly accessible code. You can explore the final result by visiting the or itself. repository website Keep in mind, I'll be using examples coded in . If you're not familiar with this language, don't worry - I've aimed to illustrate the fundamental concepts of atomic design, rather than focusing on the nitty-gritty details of the code. React Atoms To get a better understanding of the components in my repository, you can find them under the following directory: . In this location, I created a new directory called to maintain consistent naming with the atomic design methodology. This new directory contains all the small pieces needed to build the entire onboarding process. /client/presentation atoms The full list of atoms is as follows: atoms
├── box
├── button
├── card
├── card-body
├── card-footer
├── container
├── divider
├── flex
├── form-control
├── form-error-message
├── form-helper-text
├── form-label
├── heading
├── icon
├── input
├── list
├── list-icon
├── list-item
├── spinner
├── tab
├── tab-list
├── tab-panel
├── tab-panels
├── tabs
└── text These atom names may be familiar to you since they are based on the package. Most of them already contain the default matching style for my application, so there isn't anything particularly unique to describe at this level. With that in mind, we can proceed directly to discuss the . Chakra UI molecules Molecules At this stage, the atomic design process becomes more interesting and its true power starts to reveal itself. While defining your base atoms may have been a time-consuming and monotonous task, building new components using atoms becomes much more enjoyable. To define the molecules, I created a directory inside of my directory. The full list of required molecules is as follows: molecules /client/presentation molecules
├── available-notion-database
├── full-screen-loader
├── input-control
├── onboarding-step-layout
└── onboarding-tab-list Indeed, with just five molecules, we have enough components to accomplish our goal. It's important to note that this is also an ideal place to include shared layouts built upon other atoms. For instance, the is utilized to maintain a consistent appearance throughout all five steps of the onboarding process. onboarding-step-layout The other components are as follows: : Used to display the fetched user's database details (users may have multiple databases, so I provide the ability to pick one in step 4). available-notion-database The component appears on the UI like this: : Used at the very beginning when I'm fetching user details to check if the user has already defined Notion integration or not. The code for this component looks like this: full-screen-loader import { FC } from 'react';
import { Flex, Spinner } from '@presentation/atoms';
import { FullScreenLoaderProps } from './full-screen-loader.types';

export const FullScreenLoader: FC<FullScreenLoaderProps> = ({
  children,
  ...restProps
}): JSX.Element => (
  <Flex
    alignItems="center"
    bg="gray.50"
    height="full"
    justifyContent="center"
    left={0}
    position="fixed"
    top={0}
    width="full"
    zIndex="9999"
    {...restProps}
  >
    <Spinner />
    {children}
  </Flex>
); There's no rocket science here. This is just a combination of the already defined and atoms. flex spinner : A wrapper for the atom with , , , and to show whether there is some background action happening. The component appears on the UI like this: input-control input form-label form-control form-error-label spinner : This is basically a step component, but in my case, I'm using tabs for navigation, so that's where the name comes from. The component appears like this: onboarding-tab-list Chakra UI Now that more pieces are ready, we can move on to defining larger blocks in our design puzzle. Organisms This section is where I create each component responsible for displaying each step of the onboarding process. To clarify things, I'll just show you the list of created organisms: organisms
├── onboarding-step-one
├── onboarding-step-two
├── onboarding-step-three
├── onboarding-step-four
└── onboarding-step-five I believe the names are self-explanatory, and there should be no misunderstandings. To illustrate how I put everything together, I will present the code of one step as an example. Of course, if you want to check more, just visit . my repository export const OnboardingStepFour: FC<OnboardingStepFourProps> = ({
  onBackButtonClick,
  onNextButtonClick,
}): JSX.Element => {
  const { hasApiTokenData, isSetApiTokenLoading, setApiToken, setApiTokenError } = useSetApiToken();

  const handleInputChange = debounce(async (event: ChangeEvent<HTMLInputElement>) => {
    const result = await setApiToken(event.target.value);

    if (result) {
      onNextButtonClick();
    }
  }, 1000);

  return (
    <OnboardingStepLayout
      subtitle="Paste your copied integration token below to validate your integration."
      title="Validate your integration"
      onBackButtonClick={onBackButtonClick}
    >
      <InputControl
        isRequired
        errorMessage={setApiTokenError || undefined}
        isDisabled={isSetApiTokenLoading || hasApiTokenData}
        isLoading={isSetApiTokenLoading}
        label="Integration token"
        name="integrationToken"
        placeholder="Your integration token"
        onChange={handleInputChange}
      />
    </OnboardingStepLayout>
  );
}; This code is entirely responsible for displaying step four in my onboarding process. I believe the only concern you might have is about making requests in organisms. Is this acceptable? There isn't a one-size-fits-all answer, and I need to respond to these concerns with "It depends". It depends on your structure. If including an API call within a molecule or organism makes sense in the context of your application and does not overly complicate the component, it can be an acceptable solution. Just be cautious not to let presentation components become too tightly coupled with data-fetching or business logic, as it can make them more challenging to maintain and test. In my scenario, this component is used in one place, and other solutions for performing an API call in that scenario are more complex and might produce way more code than necessary. Templates At this stage, the focus is on the structure and arrangement of the components rather than on the finer details of the UI. Templates also help to identify where state management should reside, which is usually in the page components that use the templates. In the provided code example, we have an component that serves as a template: Onboarding import { FC } from 'react';
import { Flex, Heading, TabPanels, Tabs, Text } from '@presentation/atoms';
import { OnboardingTabList } from '@presentation/molecules';
import {
  OnboardingStepFive,
  OnboardingStepFour,
  OnboardingStepOne,
  OnboardingStepThree,
  OnboardingStepTwo,
} from '@presentation/organisms';
import { OnboardingProps } from './onboarding.types';

export const Onboarding: FC<OnboardingProps> = ({
  activeTabs,
  createNotionIntegrationTabRef,
  displayCreateNotionIntegrationTab,
  displaySelectNotionDatabaseTab,
  displayShareDatabaseIntegrationTab,
  displayValidateIntegrationTab,
  displayVerifyDatabaseTab,
  selectNotionDatabaseTabRef,
  shareDatabaseIntegrationTabRef,
  validateIntegrationTabRef,
  verifyDatabaseTabRef,
}) => (
  <Flex direction="column" overflowX="hidden" px={2} py={{ base: '20px', sm: '25px', md: '55px' }}>
    <Flex direction="column" textAlign="center">
      <Heading
        color="gray.700"
        fontSize={{ base: 'xl', sm: '2xl', md: '3xl', lg: '4xl' }}
        fontWeight="bold"
        mb="8px"
      >
        Configure your Notion integration
      </Heading>
      <Text withBalancer color="gray.400" fontWeight="normal">
        This information will let us know from which Notion database we should use to get your
        vocabulary.
      </Text>
    </Flex>
    <Tabs
      isLazy
      display="flex"
      flexDirection="column"
      mt={{ base: '10px', sm: '25px', md: '35px' }}
      variant="unstyled"
    >
      <OnboardingTabList
        activeTabs={activeTabs}
        createNotionIntegrationTabRef={createNotionIntegrationTabRef}
        selectNotionDatabaseTabRef={selectNotionDatabaseTabRef}
        shareDatabaseIntegrationTabRef={shareDatabaseIntegrationTabRef}
        validateIntegrationTabRef={validateIntegrationTabRef}
        verifyDatabaseTabRef={verifyDatabaseTabRef}
      />
      <TabPanels maxW={{ md: '90%', lg: '100%' }} mt={{ base: '10px', md: '24px' }} mx="auto">
        <OnboardingStepOne onNextButtonClick={displayCreateNotionIntegrationTab} />
        <OnboardingStepTwo
          onBackButtonClick={displayVerifyDatabaseTab}
          onNextButtonClick={displayShareDatabaseIntegrationTab}
        />
        <OnboardingStepThree
          onBackButtonClick={displayCreateNotionIntegrationTab}
          onNextButtonClick={displayValidateIntegrationTab}
        />
        {activeTabs.validateIntegration ? (
          <OnboardingStepFour
            onBackButtonClick={displayShareDatabaseIntegrationTab}
            onNextButtonClick={displaySelectNotionDatabaseTab}
          />
        ) : null}
        {activeTabs.selectNotionDatabase ? (
          <OnboardingStepFive onBackButtonClick={displayVerifyDatabaseTab} />
        ) : null}
      </TabPanels>
    </Tabs>
  </Flex>
); This component assembles atoms, molecules, and organisms to create the layout for the onboarding process. Notice that the state management and tab navigation logic has been separated from this component. The necessary state and callback functions are now received as props, allowing a higher-level "page" component to handle state and data management. Onboarding This separation of concerns keeps the template focused on the layout and structure while ensuring that state management is handled at the appropriate level. In the end, I would like to present step 4 as a final result: Pages In the context of our previous discussion, the "page" component uses the template and handles state management for the onboarding process. While the code for this specific page component is not provided here, you can find it in my repository. As mentioned, there's nothing extraordinary about the page component's code; it primarily focuses on managing the state and passing it down to the template. Onboarding Onboarding If we have a look at what atomic design looks like in practice. Let's dive into the pros and cons of this approach. No rose without thorns While atomic design offers numerous obvious benefits, such as modularity, reusability, and maintainability, it also comes with a few disadvantages that are worth considering at the beginning: : atomic design requires a well-planned structure and organization, which can be time-consuming and challenging to set up initially. It may also introduce additional complexity to your codebase, especially for smaller projects where such a granular approach may be unnecessary. initial setup and complexity : for developers new to atomic design, the methodology may have a steep learning curve. It requires a solid understanding of the different levels and how they fit together, which could be overwhelming for beginners. learning curve : implementing atomic design might involve creating a large number of small, specialized components. This can lead to increased overhead in managing and maintaining these components, particularly when a component is only used in one specific context. overhead : with the focus on creating reusable and modular components, there's a potential risk of over-engineering, where developers may spend too much time refining individual components instead of focusing on the broader application. risk of over-engineering : the success of atomic design depends on clear communication and collaboration between designers, developers, and other stakeholders. Failing to establish a common language or understanding of the methodology can lead to confusion and inconsistencies in the implementation. communication and collaboration However, this approach has its own already-mentioned strengths. Let's talk about them in more detail: : by decomposing the design into the most fundamental elements, building up the complexity of components became a more manageable task. While crafting atoms posed some challenges, creating any components based on these atoms was extremely enjoyable. scalability : the ability to reuse atoms, molecules, and organisms significantly cuts down the time spent on designing and developing new features. Once the base components are established, creating new interfaces can be as simple as combining existing elements. efficiency : comes directly from the previous point. Since the same atoms, molecules, and organisms are used across multiple templates and pages, the user interface remains uniform, providing a seamless experience for users. consistency : atomic design inherently supports documentation. The atom-based structure can serve as a clear, visual guide for how components should be built and used. This can be especially helpful for onboarding new team members. documentation : one of the greatest strengths of atomic design is how it contributes to the maintainability of a design system. By breaking everything down into its atomic parts, any changes or updates can be made at the atomic level and then propagated through the system. For example, if you decide to change the color of a button, you only need to make this change once at the atom level, and it will be reflected across all the molecules, organisms, and templates where this button is used. This greatly simplifies the process of updating and maintaining the design system over time. maintainability Conclusion In conclusion, while atomic design may seem like a double-edged sword - a bit daunting in terms of initial setup and learning curve - its potential benefits are well worth the initial struggle. And remember, even the most formidable swords are harmless in the hands of a skilled knight!

The Double-Edged Sword of Atomic Design

পারমাণবিক ডিজাইনের ডাবল-এজড সোর্ড

Das zweischneidige Schwert des Atomdesigns

La espada de doble filo del diseño atómico

L'épée à double tranchant de la conception atomique

परमाणु डिजाइन की दोधारी तलवार

アトミックデザインの両刃の剣

원자 디자인의 양날의 검

A espada de dois gumes do design atômico

Atomik Tasarımın İki Kenarlı Kılıcı

Con dao hai lưỡi của thiết kế nguyên tử

原子设计的双刃剑

Thinking like an attacker In today's threat environment, it's more important than ever to have a well-trained and effective blue team that can confidently respond to threats. Red teams, or people who emulate attackers, are essential in identifying vulnerabilities and gaps in an organization's defenses. However, developing the skills necessary to be a successful “redteamer” is difficult and time-consuming. The Atomic Red Team (ART) is a collection of automated attacks that can help security professionals learn the tools and techniques needed to be successful red teamers. In this blog post, we'll explore how ART can be used to train and improve the effectiveness of your red team. What is Atomic Red Team (ART)? Atomic Red Team (ART) provides security teams with a valuable tool for testing and improving their detection capabilities. ART is an automated collection of Attacker Tactics, Techniques, and Procedures (TTPs) developed to simulate threats from an adversarial perspective. With ART, security teams can better understand the behavior they should be looking for in order to detect attacks. Furthermore, utilizing ART gives teams a chance to continuously learn by creating new detections when results aren't as expected. Overall, it helps create resilient organizations with a more sophisticated security posture. Where did Atomic Red Team come from? Red Canary is a provider of cyber security services and products. Founded in 2012, Red Canary provides organizations with the intelligence and insights needed to detect, investigate, and respond to threats quickly and effectively. While I am certain Red Canary does great things with its paid products, I am most familiar with its open-source project (Atomic Red Team). Atomic Red Team (ART) is a comprehensive collection of attack simulations developed by Red Canary. It is designed to help security teams better understand the behavior they should be looking for in order to detect attacks. ART can be found on . GitHub Why is it called Atomic Red Team? Atomic Red Team (ART) was named after the concept of Atomic testing. This term originated in 1945 when the United States used the atomic bomb to end World War II. Similarly, the Atomic Red Team is designed to simulate "atomic" attacks that can cause significant damage to an organization's security posture. How can ART be used to develop detections or learn about attacker TTPs? ART provides an automated collection of attacks that can be used to gain valuable knowledge on attacker tactics, techniques, and procedures (TTPs) from an adversarial perspective. Attacker TTPs are hard to pinpoint, so ART can offer a reliable way to learn more about the ways malicious actors interact with their environment. Security practitioners can use ART directly or as a basis for custom scenarios to detect and mitigate security risks. How can using ART help build better defenses? By using Atomic Red Team, organizations can help improve their defenses through well-defined attack scenarios that identify and highlight areas of improvement for existing security controls. ART enables the development of increased detection capabilities to enhance the security posture and increase the ability to mitigate future attacks. In addition, it empowers teams to learn more effective ways to respond quickly with appropriate countermeasures during a breach or other malicious activity detected within their network. Ultimately, ART allows an in-depth understanding of potential threats and provides better defenses against them. Why is the attacker perspective important when working on a blue team? When it comes to maintaining proper cybersecurity measures, having an understanding of the attacker's perspective is absolutely essential for blue teams. This is because, without full insight into how an attack could be launched or what abilities attackers possess, defensive efforts can fall short. By moving away from merely reactively responding to attacks and actively seeking to anticipate them, blue teams can benefit from using frameworks that are inspired by Red Team activities and guides like Atomic Red Team (ART). Such activities are invaluable in giving a comprehensive view of the offensive side of security and thereby arming blue teams with the skills they need to stay one step ahead of potential attackers. How to get started using ART? Taking the first steps to incorporate the Atomic Red Team (ART) into your security testing can be a daunting task. However, the benefits that ART provides, such as an automated collection of security penetration tests, make it worth all the effort. To get started with ART, it's important to have a basic understanding of what type of attacking techniques will be used and how they may interact with your system. It's also critical to becoming familiar with any relevant tools and scripts that are included in the kit and to think about how you plan to use them in your testing environment. As red team activities require difficult-to-develop skills that are hard to find, tools like ART enable organizations to get started easily and quickly. Automated collections of attacks, such as Atomic Red Team, provide great value across many areas, from detection development to education and learning.

Unlocking the Power of Expert Red Teams: How to use Atomic Red Team (ART) to Think Like an Attacker

Worlds Within Worlds: The Story of Nuclear Energy, Volume 1 (of 3), by Isaac Asimov is part of HackerNoon’s Book Blog Post series. You can jump to any chapter in this book here . Volume I: ATOMIC WEIGHTS ATOMIC WEIGHTS As long ago as ancient Greek times, there were men who suspected that all matter consisted of tiny particles which were far too small to see. Under ordinary circumstances, they could not be divided into anything smaller, and they were called “atoms” from a Greek word meaning “indivisible”. It was not until 1808, however, that this “atomic theory” was really put on a firm foundation. In that year the English chemist John Dalton (1766-1844) published a book in which he discussed atoms in detail. Every element, he suggested, was made up of its own type of atoms. The atoms of one element were different from the atoms of every other element. The chief difference between the various atoms lay in their mass, or weight. [1] Dalton was the first to try to determine what these masses might be. He could not work out the actual masses in ounces or grams, for atoms were far too tiny to weigh with any of his instruments. He could, however, determine their relative weights; that is, how much more massive one kind of atom might be than another. For instance, he found that a quantity of hydrogen gas invariably combined with eight times its own mass of oxygen gas to form water. He guessed that water consisted of combinations of 1 atom of hydrogen with 1 atom of oxygen. (A combination of atoms is called a “molecule” from a Greek word meaning “a small mass”, and so hydrogen and oxygen atoms can be said to combine to form a “water molecule”.) John Dalton To account for the difference in the masses of the combining gases, Dalton decided that the oxygen atom was eight times as massive as the hydrogen atom. If he set the mass of the hydrogen atom at 1 (just for convenience) then the mass of the oxygen atom ought to be set at 8. These comparative, or relative, numbers were said to be “atomic weights”, so that what Dalton was suggesting was that the atomic weight of hydrogen was 1 and the atomic weight of oxygen was 8. By noting the quantity of other elements that combined with a fixed mass of oxygen or of hydrogen, Dalton could work out the atomic weights of these elements as well. Dalton’s idea was right, but his details were wrong in some cases. For instance, on closer examination it turned out that the water molecule was composed of 1 oxygen atom and 2 hydrogen atoms. For this reason, the water molecule may be written H₂O, where H is the chemical symbol for a hydrogen atom, and O for an oxygen atom. It is still a fact that a quantity of hydrogen combines with eight times its mass of oxygen, so the single oxygen atom must be eight times as massive as the 2 hydrogen atoms taken together. The oxygen atom must therefore be sixteen times as massive as a single hydrogen atom. If the atomic weight of hydrogen is 1, then the atomic weight of oxygen is 16. At first it seemed that the atomic weights of the various elements were whole numbers and that hydrogen was the lightest one. It made particular sense, then, to consider the atomic weight of hydrogen as 1, because that made all the other atomic weights as small as possible and therefore easy to handle. The Swedish chemist Jöns Jakob Berzelius (1779-1848) continued Dalton’s work and found that elements did not combine in quite such simple ratios. A given quantity of hydrogen actually combined with a little bit less than eight times its mass of oxygen. Therefore if the atomic weight of hydrogen were considered to be 1, the atomic weight of oxygen would have to be not 16, but 15.87. Jöns Jakob Berzelius As it happens, oxygen combines with more elements (and more easily) than hydrogen does. The ratio of its atomic weight to that of other elements is also more often a whole number. In working out the atomic weight of elements it was therefore more convenient to set the atomic weight of oxygen at a whole number than that of hydrogen. Berzelius did this, for instance, in the table of atomic weights he published in 1828. At first he called the atomic weight of oxygen 100. Then he decided to make the atomic weights as small as possible, without allowing any atomic weight to be less than 1. For that reason, he set the atomic weight of oxygen at exactly 16 and in that case, the atomic weight of 10hydrogen had to be placed just a trifle higher than 1. The atomic weight of hydrogen became 1.008. This system was retained for nearly a century and a half. Throughout the 19th century, chemists kept on working out atomic weights more and more carefully. By the start of the 20th century, most elements had their atomic weights worked out to two decimal places, sometimes three. A number of elements had atomic weights that were nearly whole numbers on the “oxygen = 16” standard. The atomic weight of aluminum was just about 27, that of calcium almost 40, that of carbon almost 12, that of gold almost 197, and so on. On the other hand, some elements had atomic weights that were far removed from whole numbers. The atomic weight of chlorine was close to 35.5, that of copper to 63.5, that of iron to 55.8, that of silver to 107.9, and so on. Throughout the 19th century, chemists did not know why so many atomic weights were whole numbers, while others weren’t. They simply made their measurements and recorded what they found. For an explanation, they had to wait for a line of investigation into electricity to come to fruition. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Isaac Asimov. 2015. Worlds Within Worlds: The Story of Nuclear Energy, Volume 1 (of 3). Urbana, Illinois: Project Gutenberg. Retrieved May 2022 from https://www.gutenberg.org/files/49819/49819-h/49819-h.htm#c2 This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

The Story of Nuclear Energy, Volume 1 (of 3): Atomic Weights

Worlds Within Worlds: The Story of Nuclear Energy, Volume 1 (of 3), by Isaac Asimov is part of HackerNoon’s Book Blog Post series. You can jump to any chapter in this book here . Volume I, ELECTRICITY: Atomic Numbers Atomic Numbers Since the atom consisted of a positively charged nucleus at the center, and a number of negatively charged electrons outside, the next step was to find the exact size of the nuclear charge and the exact number of electrons for the different varieties of atoms. The answer came through a line of research that began with the English physicist Charles Glover Barkla (1877-1944). In 1911 he noted that when X rays passed through atoms, some were absorbed and some bounced back. Those that bounced back had a certain ability to penetrate other matter. When the X rays struck atoms of high atomic weight, the X rays that bounced back were particularly penetrating. In fact, each different type of atom seemed associated with reflected X rays of a particular penetrating power, so Barkla called these “characteristic X rays”. In 1913 another English physicist, Henry Gwyn-Jeffreys Moseley (1887-1915), went into the matter more thoroughly. He measured the exact wavelength of the characteristic X rays by reflecting them from certain crystals. In crystals, atoms are arranged in regular order and at known distances from each other. X rays reflecting from (or more accurately, diffracting from) crystals are bent out of their path by the rows of atoms. The longer their waves, the more they are bent. From the degree of bending the wavelength of the waves can be determined. Charles Glover Barkla Henry Gwyn-Jeffreys Moseley Moseley found that the greater the atomic weight of an atom, the shorter the waves of the characteristic X rays associated with it and the more penetrating those X rays were. There was such a close connection, in fact, that Moseley could arrange the elements in order according to the wavelength of the characteristic X rays. For some 40 years prior to this, the elements had been listed in order of atomic weight. This was useful especially since the Russian chemist Dmitri I. Mendeléev (1834-1907) had arranged them in a “periodic table” based on the atomic weight order in such a way that elements of similar properties were grouped together. The elements in this table were sometimes numbered consecutively (“atomic number”) but this was inconvenient since, when new elements were discovered, the list of atomic numbers might have to be reorganized. Dmitri Mendeléev and Bohuslav Brauner in Prague in 1900. Brauner was a professor of chemistry at the Bohemian University in Prague. The Danish physicist Niels Bohr (1885-1962) had just advanced a theory of atomic structure that made it reasonable to suppose that the wavelength of the characteristic X rays depended on the size of the nuclear charge of the atoms making up a particular element. Moseley therefore suggested that these X rays be used to determine the size of the positive charge on its nucleus. The atomic number could then be set equal to that charge and be made independent of new discoveries of elements. Hydrogen, for instance, has an atomic number of 1. Its nucleus carries a unit positive charge, +1, and the hydrogen atom possesses 1 electron to balance this. Helium, with an atomic number of 2, has a nuclear charge of +2 and 2 electrons, with a total charge of -2, to balance it. (The alpha particle released by radioactive atoms is identical with a helium nucleus.) The atomic number increases as one goes up the line of atoms. Oxygen atoms, for instance, have an atomic number of 8 and iron atoms have one of 26. At the upper end, thorium is 90 and uranium is 92. Each uranium atom has a nucleus bearing a charge of +92 and contains 92 electrons to balance this. Once the notion of the atomic number was worked out, it became possible to tell for certain whether any elements remained as yet undiscovered and, if so, where in the list they might be. Thus, when Moseley first presented scientists with the atomic number it turned out that there were still 7 elements that were not discovered. At least elements with atomic numbers of 43, 61, 72, 75, 85, 87, and 91 were still not known. By 1945, all seven had been discovered. It quickly turned out that the atomic number was more fundamental and more characteristic of a particular element than was the atomic weight. Niels Bohr Bohr’s study. Since Dalton’s time it had been assumed that all the atoms of a particular element were of equal atomic weight and that atoms of two different elements were always of different atomic weight. The first inkling and the first proof that this might not be so came through the study of radioactivity. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Isaac Asimov. 2015. Worlds Within Worlds: The Story of Nuclear Energy, Volume 1 (of 3). Urbana, Illinois: Project Gutenberg. Retrieved May 2022 from https://www.gutenberg.org/files/49819/49819-h/49819-h.htm#c8 This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

The Story of Nuclear Energy: Atomic Numbers

TL;DR: Some habit-building tips and tricks. If you want to change your life, you need to start with your habits. Atomic habits are the building blocks that make up our lives. They are the things we do every day, without thinking, that shape our lives. Tiny changes and baby steps are the way to great changes. Most of us have never thought about our habits. We go through the motions, day after day, without giving them much thought. But if you want to change your life, you need to start with your habits. Awareness The first step is to become aware of your habits. Habits are automated behaviors that we have learned from experience. You have to start paying attention to the things you do , without thinking. When you walk through a dark room, you don't think, you try to find the light switch. What are your morning rituals? What do you do when you first sit down at your desk? What do you do when you get off work? every day A habit is a behavior you have repeated several times. Once you become aware of your habits, you can start to change them. If you want to change your life, you need to start with your habits. Atomic habits are small habits that you can do every day to improve your life. Atomic habits are the building blocks of your success. By creating , you can improve your life without feeling overwhelmed. atomic habits Habit Formation We learn by trial and error. We tend to repeat behaviors that give a reward until they become automatic. Habits begin with a and a desire to to get a . Habits are formed through a process called " ." This is when we associate a certain stimulus with a certain behavior. trigger change reward classical conditioning Let’s say you’re trying to form the habit of going to the gym. The stimulus would be the gym itself. And the behavior would be working out. Every time you see the gym, you’re going to be reminded to work out. This association will become so strong that you’ll start to work out automatically, without even thinking about it. This is the power of classical conditioning. And it’s how we form all habits. Baby Steps Atomic habits are small and easy to do, but they can have a big impact over time. If you want to eat healthier, you could start by adding a salad to your diet each day. This small change can lead to big results over time, like losing weight and feeling better. When it comes to forming new habits, we often underestimate the power of small, incremental changes. We tell ourselves that we need to make radical overhauls to our lives to see results. Even the smallest adjustments can lead to big results over time. This is the principle of “compounding” – small changes compound to create large results. And it’s the key to making lasting change in your life. Going back to start working out. You know you need to exercise for at least 30 minutes a day to see results. But instead of jumping into a strenuous workout routine, you start by walking for 10 minutes a day. It doesn’t seem like much, but it’s a start. And after a week or two, you find that you have more energy and can walk for longer periods. You keep at it, and you will be able to work your way up to a full 30-minute workout. But it all started with those small, baby steps. The same principle applies to any area of your life where you want to make a change. Whether you want to eat healthier, quit smoking, or save money, it’s important to start small. Pick one area to focus on and make a realistic goal. Then, take baby steps each day to move closer to that goal. Remember, it’s the small, consistent steps that will get you there. So trust the process and be patient. The results will come. Make the habit as easy to adopt as possible removing all excuses and obstacles. An Action Plan All habits are triggered by signals or stimuli. is a plan of action to avoid stimuli (and habits). Turning off all notifications We can our environment to encourage better habits by reducing harmful stimuli and making triggers more difficult. hack A good plan of action requires concrete implementation steps and not vague intentions. I will go for a walk in the national park at 8:00 PM every night. This implementation intention is specific about (8:00 PM), (the national park), and (going for a walk) you will do. when where what Making an implementation intention is a simple way to increase the likelihood of forming a new habit. But it's not enough to have a plan, you also need to commit to following through with it. If you're serious about changing your habits, give implementation intentions a try. We can use records, calendars, notebooks, trackers, logs, and contracts to keep good habits. A habit tracker is also a healthy habit to keep you motivated. We are social animals, and sharing our commitment creates peer pressure. Attraction Habits should be attractive. We do things in or . Our brains release in pleasure situations. We also release it anticipating them like when we plan a trip. If we make a habit of something we desire, we will follow it. We can link an important not-so-desirable behavior to a pleasurable one. This is . This involves pairing an activity you enjoy with one that you find less appealing. anticipation of reward fear of punishment dopamine Temptation bundling For example, you might allow yourself to watch television only after you have completed a set number of push-ups. Temptation bundling allows you to indulge in short-term pleasure while still making progress towards your long-term goals. You will stick to your new habit, as you will be motivated to do the activities you enjoy. Temptation bundling is not a magic bullet and it will not work in every situation. It is a useful tool that you can add to your arsenal in the fight against temptation. Patience We often get impatient when we don’t see immediate results from our efforts. We want to see drastic changes right away, so we give up when we don’t see them. But if we can learn to be patient and trust the process, we can achieve anything we set our minds to. Habits should be immediately satisfying. We live in a where rewards are far away. Human brains are designed for immediate reward because this is the way our ancestors survived and evolved. They had urgent problems like seeking shelter or finding food. No planning ahead was necessary. We can attach immediate gratification and small rewards before reaching the finish line. delayed return environment Bad Habits Scrolling on social media apps is easy because it is designed for habit. We can make them more difficult by introducing artificial barriers. For example, removing the batteries of the remote control. Some Tips Here are some tips for creating atomic habits: Start small. Don’t try to change everything at once. Choose one small habit that you can easily do every day.  Getting started is the most difficult task. Make it automatic. Set up your environment so that your new habit is as easy as possible to do. For example, if you want to start exercising every day, put your workout clothes next to your bed so you can put them on as soon as you wake up. Set a reminder. Use a reminder or trigger to help you remember to do your new habit. For example, you could put a note on your bathroom mirror to remind you to brush your teeth. Be patient. Habits take time to form. Don’t get discouraged if you don’t see results immediately. Keep at it and it will become second nature. Reduce Friction. Make good habits as easy as possible and even more effortless. Break tasks into baby steps. Follow the 2-minute rule in a small incremental way. Change your environment If you want to change your habits, it is important to understand how your environment affects you. Your environment includes the people around you, your physical surroundings, and your daily routine. Each of these can influence your behavior in different ways. It is easier to stick to new habits when the people around you support your goals. If your friends and family are not on board with your plan to change, it can be difficult to stay motivated. Find a friend or family member who will help you stay accountable. Your physical environment can also influence your behavior. If your home is cluttered and chaotic, it can be difficult to focus on your goals. Create a space that is conducive to your new habits. declutter your living space and make time each day to tidy up. Your daily routine can either help or hinder your efforts to change your habits. If you fill your days with activities that you don’t enjoy, it will be harder to find the motivation to stick to your goals. Find ways to incorporate your new habits into your daily routine so that they become second nature. Making changes to your environment is an important step in changing your habits. By surrounding yourself with people and things that support your goals, you will be more likely to stick to your new habits and achieve your long-term objectives. Conclusion Atomic habits are habits that you can do every day, that will make a big difference in your life. They are the kind of habits that will help you achieve your goals. It is up to you.

The Art of Mastering Atomic Habits

In the old movie "District 13" dystopian Paris was divided into isolated blocks with huge walls. Each quarter had its own course of life which was totally different from neighboring. In some way it reminds the current state of things in the blockchain industry: there are a lot of networks, each of them, like Ethereum, Solana, and Cardano could have different protocols, qualities, and dApps. But each blockchain could have its own advantages which users of other blockchains would like to try to. So, there is a fast-emerging . For example, you plan to invest in a liquidity pool on a different blockchain, move assets from a sidechain to the mainnet, or transfer crypto to a friend/seller who uses a different network. How to do this? need in and coins across various blockchains transferring tokens There are four usual : ways to transfer tokens Sell and buy. Synthetic asset. acid Atomic swap. . Cross-chain token bridge Let's take a closer look at each method of token transfer. 1) Sell A and buy B on a crypto exchange The simplest method that comes into mind is to use a crypto exchange. But it really takes a lot of time and effort. For example, we want to exchange ETH for MATIC. For this you have to: Deposit ETHs from an ERC-20 wallet to the crypto exchange. Buy MATIC, if there is a matching direct coin pair. If not – we will have to sell ETH for stable coins first, and after that – buy MATIC. Withdraw our MATICs to a wallet on Polygon. Pros of using exchanges It's the simplest method, the first which comes into mind. If you use a trusted exchange, it's quite reliable. Cons of using exchanges KYC – often you have to provide personal data to use exchanges. Takes a lot of time and action. You can lose quite a sum on exchange commissions. Sometimes it's hard to find the needed coin pair, especially for new tokens. You will have to conduct a double conversion. The exchange could not support blockchain B, so there is a chance you will not be able to move the native token B. For example, now it's impossible to move MATIC from Binance to Polygon network. Most exchanges require KYC. 2) Atomic swap – let's eradicate exchanges from the equation What are Atomic Swaps? Atomic swaps help to quickly exchange two separate coins running on different blockchains. It applies time-locked smart contracts to allow users to exchange currencies straight from their crypto wallets. How does it work? Let's put it very simply and imagine that Rick wants to exchange a pizza for a burger, and be 100% sure that there will be no fraud. For this, he puts the pizza into transparent box A, and his friend Morty, who finally has agreed to share food, puts the burger into transparent box B. Both boxes are locked with the same cipher, issued by Rick. If he uses the cipher, it will become known to Morty. The exchange has happened, each party has the needed box and can ensure that there is the food they expected. After that Rick uses his cipher to open box B, which automatically provides Morty the code to open his box A and enjoy the pizza. Of course, it's a very simplified explanation and the hard reality of atomic swaps is far more complicated (just kidding, atomic swaps make our life better). In the "blockchainian" language boxes are called HTLC – Hashed Timelock Contract, burgers and pizzas represent coins, and cipher is used for Preimage – the key that simultaneously unlocks the smart contract for both parties. One of the main features of atomic swaps is that if one of the parties doesn't approve the transaction during a certain amount of time – the whole deal is canceled, so the risks are low. Actually, the term "atomic" is responsible for that – it means that the deal can be done only on defined terms or there is no deal at all. 0 or 1, nothing more. Pros of atomic swaps You have complete control over your digital assets during a transaction. pizza The HashLock and TimeLock technologies in HTCL smart contracts provide reliable security and assurance to traders. Each side has the promise of receiving their assets back in case of delays or conflicts. Low or even zero operating costs and fees compared to using centralized exchanges. No need to engage with centralized intermediaries. Everything according to DeFi values 🙂 Cons of atomic swaps Atomic swaps are only useful for swapping when both sides have already agreed on the assets and price. As a result, they have a relatively limited range of applications. Such a method cannot be used to create cross-chain collateralized derivatives, automated market-makers, and other similar products. Both currencies that are being exchanged must have the same hash algorithm and support specific types of smart contracts. Some technical skills are still needed to conduct an atomic swap. Atomic swaps require significant time to work properly. Both parties could purposely act slowly, monitoring market conditions to see if the swap remains profitable. A market fluctuation could make the swap unattractive to one party, who may then cancel the swap. Atomic swaps have more restrictive trade conditions than exchange platforms. They require parties to interact without direct communication. Platforms, for example, can perform trades with a click, while atomic swaps require the exchange of data and information. Few wallets support atomic swaps. 3) Synthetic assets. Let's make a clone and freeze the original? What is a synthetic asset? Smart contracts allow the creation of digital assets which price is pegged to the price of another asset: a cryptocurrency, stock, or US Dollar. So, you will not have the original asset itself, but an analog that has the same value. Such assets are called synthesized. In terms of transferring tokens, synthetic assets allow buying the representation of the native token of blockchain A on blockchain B, and its price will be the same as the original one. For example, you want to "transfer" Solana tokens to Ethereum. For this, you use a derivatives liquidity protocol to issue a synthesized SOL token on the Ethereum blockchain. The price of this token is tied to the price of SOL, but it could be freely used in the ERC-20 network. Pros of synthetic assets Anyone with access to open-source protocols can create blockchain-based synthetic assets. Synthetic assets are blockchain assets like ERC-20 tokens; you can send and receive them between standard cryptocurrency wallets. You can create synthetic representations not only of blockchain assets, but also equities, silver/gold, and other assets without having to hold them. Cons of synthetic assets For the most part, synthetic assets are developed on the Ethereum blockchain, so you can't issue them on most others. You can't simply exchange a synthetic asset for the underlying. If you have synthetic BTC but desire real BTC, you must find a counter-party ready to execute that exchange with you. And one could still ask for a fee. Synthetics are not able to interact with other chains. Unless paired with another interoperability solution, a synthetic that has been issued on one blockchain can only interact with contracts and assets of only this network. During periods of high market volatility, liquidity mechanisms for synthetic assets could fail and it will be hard to sell them. This is dangerous because excessive market volatility is exactly when you want your assets to be the most stable. 4) Blockchain bridges – the future of interconnected blockchain world What is a Blockchain Bridge? If we use a metaphor from fantasy fiction, the blockchain bridge is kind of a portal between parallel worlds. It allows you to easily transfer tokens, coins, and NFTs from one blockchain to another. Both can have different rules, governance models, and protocols, but the bridge provides a dependable way for interoperation. For now, the is the best way found to solve the issue of interoperability between blockchains. It allows to seamlessly transfer tokens from one blockchain to another and make use of dApps hosted on other networks. Imagine that you have ETH, but you want to invest it into a new and very profitable DeFi service on Solana. You can't interact with Solana dApps using Ethereum tokens, but token bridges solve this problem. blockchain bridge In short, blockchain bridges allow users to access the benefits of other blockchains without sacrificing the advantages of the host chain. How do blockchain bridges work? Actually, the assets are not transferred from blockchain "A" to blockchain "B", as you could think. Instead, it uses the "lock and mint" process. The bridge locks the assets in a smart contract on blockchain A and mints an equal amount of assets on blockchain B. When the user wants to redeem the tokens, the same amount of them are burned on blockchain B and the original tokens are unlocked. It prevents the assets from using on both chains at the same time. Another way that a token can be transferred via the token bridge is by using liquidity pools. User locks native X tokens on Polygon liquidity pool. The user receives native X tokens on Solana, that are sent from the liquidity pool of X tokens on Solana. It works like a usual swap, but pools are on different blockchains and the token is the same. It could sound a bit complicated, but from a user's point of view, it's very simple. For example, helps to transfer both native and wrapped tokens just in a few minutes: Allbridge.io Pros of blockchain bridges The cost of transferring tokens usually is very low. The speed of transactions is as fast – transactions take as much time as a regular token transfer would take. Bridges are very flexible and can be connected between lots of different blockchains. Cons of blockchain bridges Since you lock your assets in the contract, you must trust the creators of it. Even if the code is open source and the bridge is decentralized, there is always a chance of a hack. When the market is volatile, there is a possibility, that the price of the original token and the wrapped token can differ. If the blockchain, you are sending your tokens to, doesn't have a developed DeFi ecosystem, you may not be able to use it in dApps. So, what method is the best to transfer tokens between blockchains? Surely, everybody will choose his or her own way, depending on goals, time, and budget. However, the most accessible and modern way is to use our . It combines the best from the transfer methods we mentioned above and allows you to access the advantages of other blockchains in a few clicks. blockchain bridge

Stories, News & Mentions about ATOMIC

Atomic’s Stories on HackerNoon