# System Contracts

To simplify the zero-knowledge circuits and facilitate straightforward extensions, a significant portion of the logic within Ola has been relocated to what we refer to as "system contracts." These specialized contracts possess unique privileges and are dedicated to specific tasks, such as contract deployment and ensuring that users are only charged once for publishing contract data.

The source code for these system contracts will remain private until it has undergone rigorous testing. This section will equip you with the essential knowledge required to develop on the Ola platform.

System contracts in Ola are a set of contracts that have special privileges and serve special purposes. They handle a large chunk of the logic of Ola, such as the deployment of contracts and ensuring that the user pays only once for publishing contracts' calldata.

There are several system contracts that support the Ola network interaction, including:

### Entrypoint

To enhance extensibility and reduce overhead, certain aspects of the protocol, such as account abstraction rules, have been transitioned to an Entrypoint contract. We refer to it as "ephemeral" because it is never deployed and cannot be invoked directly. Nevertheless, it does possess a formal address, which serves as msg.sender when interacting with other contracts.

The Entrypoint is now accessible and open-source within the codebase.

### ContractDeployer

This contract plays a pivotal role in the deployment of new smart contracts. Its primary responsibility is to ensure that the bytecode for each deployed contract is properly recorded and acknowledged. Additionally, this contract defines the derivation address. Each time a contract is successfully deployed, it triggers the emission of the ContractDeployed event (To Be Done).

### DefaultAccount

The DefaultAccount system contract within the Ola ecosystem is designed to cater to accounts that do not have custom implemented logic, resembling what are commonly known as Externally Owned Accounts (EOAs) in Ethereum. These accounts serve as user addresses without specific custom code.

* Signature Verification:

  DefaultAccount handles the critical task of signature verification for transactions and messages sent from these accounts. It ensures that transactions are authenticated and legitimate.
* Secure Operations:

  This system contract provides a secure environment for standard account operations, guaranteeing the integrity and confidentiality of user interactions within the Ola network.
* Compatibility with EOAs:

  DefaultAccount is structured to offer a similar user experience to EOAs on other blockchain networks, making it easy for users to adapt to the Ola environment.

By offering a default implementation for accounts without custom logic, DefaultAccount plays a fundamental role in ensuring the smooth operation of the Ola blockchain while maintaining the security and integrity of user transactions.

### NonceHolder

The NonceHolder system contract within the Ola blockchain ecosystem plays a crucial role in storing account transaction nonces, primarily aimed at preventing transaction replay attacks. The NonceHolder system contract offers two distinct nonce incrementation methods:

* Sequential Incrementation (Compatible with Ethereum):

  In this mode, nonces increment sequentially, following a pattern such as 1, 2, 3, and so on. This method is compatible with Ethereum's nonce incrementation approach and is suitable for scenarios where maintaining a strict transaction order is necessary, effectively preventing transaction confusion and replay.
* Arbitrary Numerical Nonces:

  The second method allows for nonces to increment in an arbitrary numerical fashion. As long as the selected nonce has not been previously used for the respective account, users can assign nonces in any order. This flexibility is beneficial for transactions that do not require a specific order but need to ensure the uniqueness of nonces.

### KnownCodeStorage

The KnownCodeStorage system contract in the Ola blockchain ecosystem is an integral component responsible for maintaining a repository of known contract bytecode hashes. When a contract is deployed within the Ola network, its actual bytecode is not stored; instead, a specially formatted hash of the bytecode is retained. This hash, representing the contract's bytecode, is recorded within the KnownCodeStorage contract upon a successful deployment. It plays a pivotal role in ensuring that the operator can efficiently recognize and verify the bytecode in subsequent transactions without the need to store the complete bytecode, thereby enhancing efficiency and security.

### AccountCodeStorage

The AccountCodeStorage system contract in Ola is designed to establish associations between contract addresses (address) and their corresponding bytecode hashes. This crucial linkage aids in the management of contract deployments, ensuring that the operator can effectively locate and validate information related to specific contracts. It stores the bytecode hashes and their affiliations with contract addresses, enabling a streamlined approach to handling contract-related data and maintaining the integrity of the Ola blockchain.
