Accounts

In Ola, every account is implemented as a smart contract, providing the rules for determining the validity of transactions. This allows for the implementation of various transaction signing schemes, nonce management, and fee payments. However, commitments and nullifying keys, which are specific to private blockchains, are still integral to the protocol.

In this section, we will delve into how Ola defines AA (Account Abstraction) and its connection to private keys and viewing keys. We will cover the following topics:

• The significance and implications of Account Abstraction (AA).

• Understanding account contracts and wallets within the context of Ola.

• Exploring the concept of authorization and actions, including private key and view key.

What is Account Abstraction in Ola?

Account Abstraction (AA) in Ola refers to the ability to programmatically define the validity conditions of a transaction. In Ola, AA is divided into three distinct components:

1. Signature Abstraction: This component defines when a signature is considered valid.

2. Fee Abstraction: It handles the payment of fees associated with transactions.

3. Nonce Abstraction: This component provides features such as replay protection and transaction ordering.

In most AA schemes within Ola, a user's identity is no longer represented by a traditional keypair but by a contract, often referred to as a smart contract wallet or account contract. This contract receives transaction payloads, validates them using custom logic, and interprets them as actions to execute, similar to invoking another contract.

Account Abstraction in Ola offers numerous advantages, including social recovery, multi-factor authentication (MFA), batching, session keys, sponsored transactions, fee payment in kind, and support for key schemes from different realms. For more detailed information, you can refer to EIP4337.

Accounts in Ola

Ola does not incorporate the concept of Externally Owned Accounts. In Ola, every account is structured as a contract. Account contracts in Ola usually feature an entrypoint function responsible for receiving actions to be executed along with an authentication transaction. In pseudocode:

pk: PublicKey

fn ExecuteTransaction(_transaction) {
    // Signature validation
    let { privateCalls, publicCalls, nonce, signature } = _transaction;
    let payloadHash = hash(privateCalls, publicCalls, nonce);
    validateSignature(this.pk, signature, payloadHash);

    // Local private execution
    for privateCall in privateCalls {
        let { to, data, value } = privateCall;
        call(to, data, value);
    }

    // Remote public execution
    for publicCall in publicCalls {
        let { to, data, value, gasLimit } = publicCall;
        call(to, data, value, gasLimit);
    }
}

Private& View key

The account private key in Ola is utilized to authorize a transaction, which results in the modification of the global state of account notes. The account view key, on the other hand, is employed for the decryption of account notes, which are encrypted under the user's account address. Ultimately, the account address serves as the means for users to engage with one another, facilitating the transmission and reception of notes containing encoded values and application data.

To ensure the security of user assets and note data, it is imperative never to divulge the account private key to any third parties. In practical Ola applications, users are encouraged to derive a compute key from their account private key, enabling third parties to trustlessly execute applications and generate transactions on the user's behalf.