DOCSEARCHbyAlgolia
Submit Docs

Runtime RPC Documentation

website·Indexed 30 days ago

https://docs.runtime-rpc.com

Guides, scripts, and resources from The Republic Crypto Runtime Team, featuring blockchain infrastructure setup. Includes Ansible tutorials, the republic.crypto and republic.infra Ansible Galaxy collections, and chain-specific documentation for Berachain, Cosmos, Avalanche, and Aptos.

Tokens
7.8K
Snippets
57
Records
76
Agent score
50%

What's inside Runtime RPC

  1. Overview of Aptos Blockchain Architecture

    Aptos is a decentralized blockchain platform designed for Web3 applications, focusing on scalability and security. Its core architecture is defined by three primary technical pillars:

    1. Parallel Execution (Block-STM): Unlike traditional sequential processing, Aptos uses the Block-STM engine to process multiple transactions simultaneously, resulting in high throughput and low latency.
    2. Modular Design: The architecture allows developers to build and modify components independently, simplifying network upgrades and scaling.
    3. Move Programming Language: Aptos utilizes Move, a language specifically designed for secure, verifiable smart contracts with a strong focus on resource scarcity and access control.

  2. Overview of the Cosmos Network Architecture

    Cosmos is designed as an "Internet of Blockchains," a decentralized network of independent blockchains known as "zones." These zones are connected to a central mediator called the Cosmos Hub, which enables token transfers and data exchange between different chains using the Inter-Blockchain Communication (IBC) protocol.

  3. Overview of Avalanche (AVAX) Platform

    Avalanche is a Proof of Stake (PoS) blockchain platform designed to solve the blockchain trilemma of scalability, security, and decentralization. It features high throughput, low latency (near-instant finality), and is Solidity-compatible, allowing for seamless integration with Ethereum and other EVM-based ecosystems.

  4. Understand the difference between Ansible Roles and Collections

    Ansible Galaxy hosts two primary types of reusable content:

    • Roles: Groups of tasks, templates, and handlers designed to accomplish specific functions.
    • Collections: A more advanced packaging system (introduced in Ansible 2.9) that bundles multiple roles, plugins, modules, and documentation into a single package. For example, republic.crypto is a collection containing roles for managing blockchain infrastructure.

  5. Use Ansible Facts as dynamic variables

    Ansible automatically gathers system information (facts) about target hosts (e.g., OS distribution, IP address) via the gather_facts feature. These are accessible using the ansible_facts dictionary.
    - name: Display the operating system
  debug:
    msg: "The system is running {{ ansible_facts['distribution'] }} {{ ansible_facts['distribution_version'] }}"

  6. Understand Berachain V2 Modular Client Architecture

    v1-vs-v2

    Berachain V2 introduces a decoupled architecture that separates the consensus layer from the execution layer to improve scalability and stability. Unlike V1 (Artio), which used a single client (Polaris) for both functions, V2 requires a dual-client setup:

    1. Consensus Layer: Handled by the BeaconKit client.
    2. Execution Layer: Handled by an EVM-compatible execution client (e.g., Geth or Erigon).

    This modularity allows validators to upgrade or switch execution clients independently without affecting the consensus layer and ensures full EVM-identical execution for seamless contract deployment.

  7. Understand the republic.crypto role execution lifecycle

    Roles within the republic.crypto collection generally follow a five-phase execution sequence, although not every role implements every phase:

    1. Load variables
    2. Install binaries
    3. Initialize blockchain node
    4. Set configuration
    5. Sync chain data from public backup (if applicable)

  8. Compare Berachain V1 (Artio) and V2 (BeaconKit) Specifications

    v1-vs-v2

    The transition from V1 to V2 involves significant changes to the client architecture, token utility, and risk models:

    FeatureV1 (Artio)V2 (BeaconKit)
    Client ArchitectureSingle client (Polaris)Modular: BeaconKit (Consensus) + EVM client (Execution)
    Native Token for Validators$BGT$BERA
    Slashing RisksAffects both delegators and validatorsAffects only validators; removed for $BGT delegators
    Execution EnvironmentCustom EVM-compatibleEVM-identical
    Consensus LayerTightly integrated (Polaris)Decoupled (BeaconKit)
    Token Utility$BGT for governance
    $BERA for validator activation; $BGT for PoL governance and incentives
    ThroughputLimited scalability under loadImproved performance and scalability

  9. Understand Berachain V1 (Artio) and V2 (bArtio) Testnet differences

    Berachain evolved from V1 (Artio) to V2 (bArtio) to address scalability and performance limitations.

    V1 (Artio) was built on the Polaris framework, integrating EVM execution with Cosmos-based consensus.

    V2 (bArtio), launched June 9th, introduced the BeaconKit framework. BeaconKit improves network performance and flexibility by separating the consensus layer from the execution layer, utilizing a modular client architecture to support EVM innovations and future updates.

  10. Understand Ansible Role concepts and structure

    Ansible Roles allow you to organize tasks, variables, files, and templates into a modular and reusable structure. This is essential for maintaining large projects and sharing common configurations across different environments.

    An Ansible role follows a specific directory structure:

    • tasks/main.yml: The main list of tasks to be executed.
    • handlers/main.yml: Tasks triggered by notifications (e.g., restarting a service).
    • templates/: Jinja2 templates for dynamic configuration files.
    • files/: Static files to be copied to hosts.
    • defaults/main.yml: Default variables (lowest priority, easily overridden).
    • vars/main.yml: Variables specific to the role.
    • meta/main.yml: Role metadata and dependencies.
    • README.md: Documentation for the role.
    roles/
└── myrole/
    ├── defaults/
    │   └── main.yml
    ├── files/
    ├── handlers/
    │   └── main.yml
    ├── meta/
    │   └── main.yml
    ├── tasks/
    │   └── main.yml
    ├── templates/
    ├── vars/
    │   └── main.yml
    └── README.md

  11. Understand Ansible Playbook core concepts

    Ansible Playbooks are structured YAML files used to automate tasks on remote systems by defining a desired state. Key components include:

    • Plays: Sets of tasks mapped to specific hosts.
    • Tasks: Individual actions to be performed.
    • Modules: The actual units of work executed by tasks (e.g., ansible.builtin.apt).
    • Roles: Reusable components that group tasks and variables for better organization.

  12. Apply a role in an Ansible playbook

    To use a role, reference it under the roles section of a playbook. You can apply a role simply by name or provide specific variables to override the role's defaults.
    ---
- name: Apply role to configure Nginx
  hosts: webservers
  become: true
  roles:
    - role: nginx
      vars:
        nginx_conf_path: /custom/path/nginx.conf