diff --git a/docs/Protocol/Protocol_v2/_category_.json b/docs/Protocol/Protocol_v2/_category_.json new file mode 100644 index 00000000..48f2a62e --- /dev/null +++ b/docs/Protocol/Protocol_v2/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "Protocol v2", + "position":1, + "link": { + "type": "generated-index", + "description": "Dive into the technical details of the new components and features of the Protocol that makes it more scalable, lightweight and decentralized." + } + } \ No newline at end of file diff --git a/docs/Protocol/Protocol_v2/overview.md b/docs/Protocol/Protocol_v2/overview.md new file mode 100644 index 00000000..5c9df055 --- /dev/null +++ b/docs/Protocol/Protocol_v2/overview.md @@ -0,0 +1,70 @@ +--- +sidebar_position: 0 +--- + +# Overview + + +## Necessity of an upgrade + +After running multiple iterations of our incentivized testnets, inclding the latest version that engaged 5000+ Snapshotter Lite nodes, we gathered valuable metrics and data on the performance of the initial approach of our protocol. + +### Protocol State Bloat + +The snapshot submissions were so far resolved on a Solidity smart contract deployed on the Prost chain that acts as the consensus and reward mechanism for peers participating in the protocol. + +This causes a state bloat of submissions for base snapshots for thousands of project IDs across 5000+ nodes, for every epoch. For a real time data market that updates every second, that is 86400 epochs in a day. Once the consensus on these snapshots have been validated, the data included in them becomes part of the higher order, composed datapoints and can be safely discarded from the chain state. + +:::info +Learn more: + +* [Protocol State](/docs/Protocol/Specifications/protocol-state.md) +* [Snapshot Generation](/docs/Protocol/Specifications/Snapshotter/snapshot-build.md) +* [Introduction to Snapshotting consensus](/docs/build-with-powerloom/snapshotter-node/introduction) +* [Accessing datasets on which consensus has been reached](/docs/build-with-powerloom/snapshotter-node/data) +::: + +### Relayer transaction and chain infrastructure failures + +The above approach required the snapshotter peers to send out their submissions to the contract as an EIP-712 signed message object. This mechanism allowed us to trustlessly operate an infrastructure of relayers that would receive these submissions as HTTP POST requests and ultimately commit to the chain as EVM transactions. But at a scale of operation that exceeded 1 million snapshot submission transactions per day, this would often result in a significant percentage (>5%) of transactions being dropped along with other operational issues with maintaining the chain at a continuously running state. + +### Composed snapshots finality + +A combination of the above couple of issues also affects the [composability principle](/docs/Protocol/data-composition.md) of building higher order snapshots. Dropped transactions and increased delays in confirmation times of snapshot submissions ultimately affect the aggregate data points that power complex use cases like the [Uniswap V2 dashboard](/docs/build-with-powerloom/use-cases/existing-implementations/uniswapv2-dashboard/) and [Aave V3 dashboard](/docs/build-with-powerloom/use-cases/existing-implementations/aavev3-dashboard/). + + +## Upgraded workflow + +The next iteration of the Powerloom Testnet and the upcoming Mainnet Alpha feature new components that are: + +* more accessible geographically +* scalable +* contribute to faster finality of composed snapshots + +![new architecture workflow](/images/new_architecture_workflow.png) + +It notably features the following components that make this possible. + +### Local collector: Snapshotter node + +The snapshotter node replaces the [payload commit service](/docs/Protocol/Specifications/Snapshotter/payload-commit-service.md) component with a faster grpc based service referred to as local collector. As the name suggests, it acts as a collection point for a stream of large number of [snapshots being built out](/docs/Protocol/Specifications/Snapshotter/snapshot-build.md) by the compute modules as specified in its configuration. + +It is responsible for reliably submitting all the generated snapshots to the sequencers via circuit relay nodes. + +### Sequencer + +The sequencer is a vital component in the upgraded workflow of the protocol. It batches submissions from multiple snapshotters within the active time window of an epoch, uploads them to IPFS and anchors the proof for the same on the protocol state contract. + +* [Read more: Offchain sequencer](./sequencer.md) + +### libp2p circuit relay nodes + +The snapshot collector is ultimately able to submit snapshots to the sequencer component referenced above thanks to nodes that implement the [libp2p circuit relay protocol](https://docs.libp2p.io/concepts/nat/circuit-relay/). + +* [Read more: Circuit relay nodes](./relay.md) + +### Validator + +The upgraded protocol now supports validation on snapshot batches as submitted by the sequencer. The validators submit attestations for the fact that finalized snapshots across projects as reported by the sequencer are correct. + +* [Read more: Validator](./validator.md) \ No newline at end of file diff --git a/docs/Protocol/Protocol_v2/relay.md b/docs/Protocol/Protocol_v2/relay.md new file mode 100644 index 00000000..c2490d8c --- /dev/null +++ b/docs/Protocol/Protocol_v2/relay.md @@ -0,0 +1,52 @@ +--- +sidebar_position: 2 +--- + +# Relayers + +## Recap + +Powerloom Protocol V1 that powered the Incentivized testnets and the Lite Node testnet were able to submit their snapshots to the protocol state in the following manner: + +1. The nodes submit their snapshots over HTTP to the relayers as EIP-712 signed message objects +2. The relayers submit each node's submission against each project ID as [individual smart contract transactions to the method `submitSnapshot()`](/docs/Protocol/Specifications/protocol-state.md#function-submitsnapshotstring-memory-snapshotcid-uint256-epochid-string-memory-projectid-request-calldata-request-bytes-calldata-signature-public) + +## What's new in V2 + +V2 relayers make use of the circuit relay transport protocol as implemented by the `libp2p` project. Briefly stated, this has two major advantages: + +* Faster, lightweight connections + * Avoids overheads associated with HTTP connections: connection management, establishment, pooling, message payload size +* More geographically available and censorship resistant + +To quote from the docs on circuit relays, + +``` +When a peer isn’t able to listen on a public address, it can dial out to a relay peer, +which will keep a long-lived connection open. + +Other peers will be able to dial through the relay peer using a +`p2p-circuit` address, which will forward traffic to its destination. +``` + +:::info +[libp2p docs: Circuit Relay](https://docs.libp2p.io/concepts/nat/circuit-relay/) +::: + +## Connection overview + +As stated in the Protocol V2 overview, the circuit relay nodes ultimately allow the snapshotter nodes to connect and submit to the sequencer node. This is intermediated further by the [Rendezvous protocol](https://docs.libp2p.io/concepts/discovery-routing/rendezvous/). + +:::note +Rendezvous points are typically nodes that are well-connected and stable in a network and can handle large amounts of traffic and data. They serve as a hub for nodes to discover. +::: + +The setup for the nodes includes `env` details that encapsulate sequencer ID(s), and the rendezvous points which intermediate and facilitate the connection between snapshotters, relayers and sequencer(s). + +## Final destination: Sequencer + +The circuit relay nodes ultimately allow Snapshotters on the Powerloom network, located anywhere in the world, to submit their snapshots to the sequencer. + +![snapshotter to sequencer via relay network](/images/SequencerRelayNetwork.png) + +In future upgrades of the protocol, we will begin supporting a decentralized network of sequencers with its own incentive and reward structure. \ No newline at end of file diff --git a/docs/Protocol/Protocol_v2/sequencer.md b/docs/Protocol/Protocol_v2/sequencer.md new file mode 100644 index 00000000..0e1f00ef --- /dev/null +++ b/docs/Protocol/Protocol_v2/sequencer.md @@ -0,0 +1,54 @@ +--- +sidebar_position: 1 +--- +# Sequencer + +![Powerloom Protocol V2 sequencer](/images/Sequencer.png) + +The sequencer has the following primary functions: + +1. **Snapshot Collection:** Receive snapshot submissions per epoch across project IDs from all participating snapshotters in a data market +2. **Snapshot Finalization:** Finalize snapshot submission for each project ID according to consensus rules +3. **Batch Upload Snapshot Submissions:** Create multiple batches of datasets of snapshot submissions and finalized CIDs across project IDs within an epoch. +4. **Anchor Proof of Batch:** Upload these batches to IPFS or a decentralized storage layer. Commit the storage identifier to the protocol state smart contract for validators and other peers to reference for subsequent workflows according to their roles. + + +## Snapshot collection and finalization + +The sequencer maintains an internal clock corresponding to the release and end of the submission window for an epoch. The collector component (not to be confused with the local collector component within a Snapshotter node) receives snapshot submissions from snapshotter peers over a libp2p circuit relay node. + +It also performs important verification checks: + +* identity verification by referencing an EIP-712 signature field contained within the submission payloads against the snapshotter identities allowed for a data market on the protocol state smart contract +* submission window verification check by referencing the protocol state head block number as attached in the header of the submission sent by a snapshotter peer + +![Collector libp2p circuit relay connection](/images/Collector-relay.png) + +As the submission window for an epoch closes, the finalized submission for each project ID is decided upon by the sequencer according to rules of consensus, out of all the submissions sent out by participating snapshotter peers. + +## Batch upload and anchor proof + +Multiple such finalizations are decided upon all project IDs within a data market and they are batched together in multiple datasets, if required, at the end of every epoch's submission window. These datasets are then uploaded to IPFS or a decentralized storage layer, and references to their storage (for eg, a content identifier aka CID) are committed to the protocol state smart contract. + +The finalized snapshot submissions for all corresponding project IDs are placed in an 'intermediate' finalized state on the protocol state. They can be considered to be trusted, but are awaiting attestation from validators that participate in the protocol. + +:::info +Read more on how validators submit attestations on intermediate finalized states +::: + + +Batches contain submission details for multiple project IDs with the following information per project: + +* Submission objects from snapshotter peers that contain their respectively signed EIP-712 objects +* Finalized snapshot as reported by sequencer + +![Batch submission section of protocol V2 workflow](/images/protov2-submission-batching.png) + +### Merkle tree of submission IDs + +An important feature of each batch is that the dataset against it contains the root hash of a Merkle tree constructed out of the submission IDs sent out by the snapshotter peers. Utilizing this, snapshotter peers can verify whether their submissions were included in batches committed to the protocol state smart contract for an epoch. + +The submission IDs contained in a batch are added to the leaves of the Merkle tree as determined by the lexicographical ordering of their corresponding project IDs. + +Each batch's Merkle tree builds on the tree from the preceding batch within the same epoch. + diff --git a/docs/Protocol/Protocol_v2/state.md b/docs/Protocol/Protocol_v2/state.md new file mode 100644 index 00000000..20a3b7b6 --- /dev/null +++ b/docs/Protocol/Protocol_v2/state.md @@ -0,0 +1,237 @@ +--- +sidebar_position: 4 +--- + +# Protocol State + +## Overview + +### Additional features + +The protocol state in V2 of the protocol has the following changes introduced to support new features like batched submissions and validator attestations: + +* Batched snapshot submissions from sequencer +* Attestation on submission batches from validators + +### Removed + +* [Method to directly accept submissions from allowed snapshotters](/docs/Protocol/Specifications/protocol-state.md#function-submitsnapshotstring-memory-snapshotcid-uint256-epochid-string-memory-projectid-request-calldata-request-bytes-calldata-signature-public) +* Snapshot submissions as content identifiers(CIDs) per epoch + * Occurrence count of their submissions + * Mapping between allowed snapshotter identities and the CIDs they submitted + + +### Continued from Snapshotter Lite testnet + +:::note +Most of the [V1 protocol state](/docs/Protocol/Specifications/protocol-state.md) implemented for the different phases of the incentivized testnets and the lite node testnet continues in V2. +::: + +* Slot based snapshotter identities (slot IDs) +* Snapshot CIDs per epoch per project with the max occurrence frequency +* Time slots allotted to slot IDs against snapshotter identities + + +## Deployed contract + +The contract address where the V2 protocol state can be found is contained within the `env.example` file for the type of node being deployed: + +* [Snapshotter Lite Node V2](https://github.com/PowerLoom/snapshotter-lite-v2/blob/15ce2872ac3cbdce47955b26f84b6c634fbbb6ab/env.example#L7) + +## ABI + +The [Application Binary Interface (ABI) to interact with the smart contract](https://github.com/PowerLoom/snapshotter-lite-v2/blob/feat/new_proto_bidirectional/snapshotter/static/abis/ProtocolContract.json) can be found contained within the repositories of the corresponding node type. + +--- + +## State transitions + +### Snapshot state + +```solidity +enum SnapshotStatus { + PENDING, + FINALIZED +} +``` +The state of a snapshot CID against a project ID is `PENDING` when reported by the sequencer and `FINALIZED` when the same is attested to by the validator. + +The `PENDING` state can be considered to be an intermediate, trusted state since it is reported by the sequencer which has no incentive to be a bad actor unless its security is compromised. + +--- + +## State modification + +### Snapshot submission in batches by [sequencer](/docs/Protocol/Protocol_v2/sequencer.md) + +```solidity +function submitSubmissionBatch( + string memory batchCid, + uint256 batchId, + uint256 epochId, + string[] memory projectIds, + string[] memory snapshotCids + ) public onlySequencer +``` + +An epoch as identified by `epochId` can contain multiple batches of snapshot submissions from the sequencer, as referenced by the `batchId`. + +The entire contents of this batch are made available on IPFS on the CID `batchCid`. + +The elements of the arrays `projectIds` and `snapshotCids` are present as a 1:1 mapping that the sequencer reports as finalized CID against each of the project IDs. + +### Attestation against submission batches by [validator](/docs/Protocol/Protocol_v2/validator.md) + +```solidity +function submitBatchAttestation( + uint256 batchId, + uint256 epochId, + bytes32 finalizedCidsRootHash + ) public onlyValidator +``` + +Validators submit their attestations against batches of snapshot submissions in an `epochId` by refererring to their `batchId`. + +The attestation is the `finalizedCidsRootHash` which is the hash of the merkle tree root constructed from the finalized CIDs across the projects contained in a batch. + +### Finalization against attestation consensus + +`shouldFinalizeBatchAttestation()` is used as the state check whether the consensus rule around attestations submitted by the network of validators is satisfied, followed by a call to `finalizeSnapshotBatch()` that finalizes the snapshot CIDs against the project IDs contained in a `batchId` for an `epochId`. + +```solidity +function shouldFinalizeBatchAttestation( + uint256 batchId, + uint256 currentAttestationCount +) private view returns (bool) +``` + +```solidity +function finalizeSnapshotBatch(uint256 batchId, uint256 epochId) private +``` +--- + +## State view + +### `allSnapshotters(address)` +Mapping to check for existence of snapshotter identity on protocol state. + +### `slotSnapshotterMapping(uint256)` + +Mapping from slot ID to registered snapshotter node's signing wallet address. + +### `timeSlotPreference(uint256)` + +Mapping from slot ID to registered time slot in a day. + +### `slotCounter()` + +Number of registered slots on the protocol state. + +### `snapshotsReceivedSlot` + +```solidity +mapping(string projectId => mapping(uint256 slotId => mapping(uint256 epochId => bool))) public snapshotsReceivedSlot; +``` +Whether snapshot was received against a slot ID within an epoch ID. + +### `maxSnapshotsCidMap` + +```solidity +mapping(string procjectId => mapping(uint256 epochId => string snapshotCid)) public maxSnapshotsCidMap; +``` + +The snapshot CID reported to have reached consensus against a `projectId` for an `epochId`. + +### `batchIdToProjects` + +```solidity +mapping(uint256 batchId => string[] projectids) public batchIdToProjects; +``` + +Project IDs contained within a Batch ID. + +### `epochIdToBatchIds` + +```solidity +mapping(uint256 epochId => uint256[] batchIds) epochIdToBatchIds; +``` + +Batch IDs of submissions sent out for an epoch by the sequencer. + +### Validator attestations + +```solidity +mapping(uint256 batchId => mapping(address => bool)) public attestationsReceived; +mapping(uint256 batchId => mapping(bytes32 finalizedCidsRootHash=> uint256 count)) public attestationsReceivedCount; +mapping(uint256 batchId => uint256 count) public maxAttestationsCount; +mapping(uint256 batchId => bytes32 finalizedCidsRootHash) public maxAttestationFinalizedRootHash; +mapping(uint256 batchId => bool) public batchIdAttestationStatus; +``` + +Storing attestations received from validator identities and their counts of attestations against finalized root hashes of merkle trees built from CIDs. + +```solidity +mapping(uint256 batchId => bytes32 finalizedCidsRootHash) public batchIdSequencerAttestation; +mapping(uint256 batchId => address[] validators) public batchIdDivergentValidators; +``` + +State of the initial attestation as reported by the sequencer as finalized CIDs against the project IDs and the state of them if they diverge from the consensus on attestations as reached by validators. + +## Events + +### Snapshot submissions + +* **SnapshotBatchSubmitted:** Emitted upon the sequencer submitting a batch of snapshot submissions along with their claimed finalizations for an `epochId` + +```solidity +event SnapshotBatchSubmitted( + uint256 batchId, + string batchCid, + uint256 indexed epochId, + uint256 timestamp +); +``` + +* **DelayedBatchSubmitted:** Emitted when the sequencer submits a batch past the submission deadline for an epoch + +```solidity +event DelayedBatchSubmitted( + uint256 batchId, + string batchCid, + uint256 indexed epochId, + uint256 timestamp +); +``` + +* **SnapshotBatchFinalized:** Emitted when a majority of the validators have submitted their attestations on a `batchId` submitted by the sequencer + +```solidity +event SnapshotBatchFinalized( + uint256 indexed epochId, + uint256 indexed batchId, + uint256 timestamp +); +``` + +### Validation + +* **SnapshotBatchAttestationSubmitted:** Emitted when a validator `validatorAddr` submits their attestation for a `batchId` batch +```solidity +event SnapshotBatchAttestationSubmitted( + uint256 batchId, + uint256 indexed epochId, + uint256 timestamp, + address indexed validatorAddr +); +``` + +* **DelayedAttestationSubmitted:** Emitted when a validator `validatorAddr` submits their attestation for a `batchId` batch past the submission deadline + +```solidity +event DelayedAttestationSubmitted( + uint256 batchId, + uint256 indexed epochId, + uint256 timestamp, + address indexed validatorAddr +); +``` diff --git a/docs/Protocol/Protocol_v2/validator.md b/docs/Protocol/Protocol_v2/validator.md new file mode 100644 index 00000000..1ed2b654 --- /dev/null +++ b/docs/Protocol/Protocol_v2/validator.md @@ -0,0 +1,36 @@ +--- +sidebar_position: 3 +--- + +# Validator + +## Overview + +![Protocol V2 validator worklow](/images/validator-workflow.png) + +As the snapshot submission batches are [anchored on the protocol state by the sequencer](/docs/Protocol/Protocol_v2/sequencer.md#batch-upload-and-anchor-proof), the validators become responsible for submitting their attestations on these batches. + +## State transitions + +![Snapshot submission, validation and finalization state transitions](/images/submission-validation-timeline.png) + +### Batch submission + +When the sequencer submits a batch, it puts the snapshots contained within in a `PENDING` state on the protocol state. It also causes the emission of a `SnapshotBatchSubmitted` event. + +:::info +Learn more: +* [Sequencer batch submission](/docs/Protocol/Protocol_v2/sequencer.md#batch-upload-and-anchor-proof) +* [Protocol State: State transition of snapshots](/docs/Protocol/Protocol_v2/state.md#snapshot-state) +::: + +### Batch validation + +The finalized CID of every project ID committed by the sequencer in the `PENDING` state moves to a `FINALIZED` state when a majority of the validators submit their attestations on that finalization. + +In the case where a majority of validators do not agree to the finalization, a resubmission workflow is triggered. This time, the validators work on re-creating the snapshots against the project IDs that did not reach consensus for finalization, and re-submit them to the protocol state to be resolved by the same consensus rules. + +#### Trigger for batch validation + +For the current iteration of the Protocol V2 release, once the sequencer for a data market has finished committing all batches of submissions, it triggers an event release `BatchSubmissionsCompleted` from the protocol state smart contract that signals the validators to begin submitting their attestations. + diff --git a/docs/Protocol/Specifications/protocol-state.md b/docs/Protocol/Specifications/protocol-state.md index a8841bf8..3ad79b41 100644 --- a/docs/Protocol/Specifications/protocol-state.md +++ b/docs/Protocol/Specifications/protocol-state.md @@ -21,6 +21,10 @@ Every [data market](/docs/protocol/data-sources) has a final state that includes - Occurrence count of their submissions - Mapping between allowed snapshotter identities and the CIDs they submitted +:::note +Powerloom Protocol V2 contains certain modifications on top of the V1 Protocol State as described in here. [Learn More](/docs/Protocol/Protocol_v2/state.md) +::: + ## Implementation of the Protocol State Presently, the protocol state is implemented as a smart contract on an EVM-compatible chain that is affectionately referred to internally as the Prost Chain. @@ -29,6 +33,10 @@ Presently, the protocol state is implemented as a smart contract on an EVM-compa Depending on the node type, the network RPC and the deployed contract address can be found in the `env.example` file in either the [`deploy`](https://github.com/Powerloom/deploy/) (for Full Nodes) and [`snapshotter`](https://github.com/Powerloom/snapshotter-lite) repositories (for Lite Nodes). +* [Snapshotter Lite Node: Testnet](https://github.com/PowerLoom/snapshotter-lite/blob/97f25850d0319b601638e46440b9bce2372551c4/env.example#L8) +* [Snapshotter Full Node: Incentivized testnet Phase 2](https://github.com/PowerLoom/deploy/blob/4af571508f832b120d18e93f48c54ddbfe6074a5/env.example#L6) + + ### ABI The [Application Binary Interface (ABI) to interact with the smart contract](https://github.com/PowerLoom/pooler/blob/main/snapshotter/static/abis/ProtocolContract.json) can be found within the snapshotter repository. diff --git a/docs/build-with-powerloom/devnet/getting-started.md b/docs/build-with-powerloom/devnet/getting-started.md index f81cee8b..7a745d00 100644 --- a/docs/build-with-powerloom/devnet/getting-started.md +++ b/docs/build-with-powerloom/devnet/getting-started.md @@ -106,11 +106,10 @@ The above command itself navigates you to the Repository Directory `powerloom_de - `PROTOCOL_STATE_CONTRACT`: Choose the contract address for the protocol state with respect to the Epoch size. :::note -Currently, there are two variations of Protocol State Contracts available. One where [Epoch](../../Protocol/Specifications/Epoch.md) size is set to 1 and the other where epoch size is set to 10 blocks. +The following protocol state contract addresses are currently operational with active epoch releases +* Data source contracts on ETH Mainnet -- [Epoch Size 1](/docs/Protocol/Specifications/Epoch.md) -- `0x573906E80C30dA608E3a24A0938BCB3f0C68Ed2f` -You can find the latest Epoch Contracts in the [example.env](https://github.com/PowerLoom/deploy/blob/devnet/env.example) file. - -This should allow developers to build and experiment with a variety of use cases. If you have any custom needs, reach out to the [team](https://discord.com/invite/powerloom) +If you have any custom requirements to track data sources on other chains, reach out to the [team.](https://discord.com/invite/powerloom) ::: **Pre-supplied:** diff --git a/docs/build-with-powerloom/snapshotter-node/lite-node/getting-started.md b/docs/build-with-powerloom/snapshotter-node/lite-node/getting-started.md index eb7ed9f4..dc8a6329 100644 --- a/docs/build-with-powerloom/snapshotter-node/lite-node/getting-started.md +++ b/docs/build-with-powerloom/snapshotter-node/lite-node/getting-started.md @@ -263,6 +263,23 @@ This will clone the repository into a directory named `powerloom-testnet`. cd powerloom-testnet ``` +** 1. Setting up Screen** + +The Screen utility allows you to run processes in the background, enabling you to maintain long-running tasks without keeping a terminal window open. To initiate a new Screen session for managing the Snapshotter Lite Node, follow these steps: + +Enter the following command to create a new Screen session named "powerloom": + +```bash + screen -S powerloom +``` + +- This command opens a new Screen session, where you can start the Snapshotter Lite Node. +- Once inside the new Screen session, initiate the Snapshotter Lite Node as required. + +This approach ensures your node can continue running in the background, even if you disconnect from the terminal session. + +** 2. Run the node** + - Run `build.sh` in the terminal to start the snapshotter lite node: ```bash @@ -587,8 +604,12 @@ It is imperative to create an isolated virtual environment that includes the nec #### Installing `Pyenv` -Follow the steps below to install `pyenv`. -Open the terminal and execute the below command to install the required packages: +Follow the steps below to install `pyenv` according to your OS. +Open the terminal and execute the below commands. + + + + ```bash sudo apt install build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev curl libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev @@ -628,6 +649,44 @@ Next, proceed to install Python 3.11.5: ```bash pyenv install 3.11.5 ``` + + + + +Install `pyenv` with the `brew` package manager. Ensure you run an update before the installation. + +```bash +brew update +brew install pyenv +``` + +Next would be to add the right initializations into your `~/.bashrc` or `~/.zshrc` file depending upon whether you use the `bash` or `zsh` shell. If you use any other shell, consult its documentation to know where the similar profile `~/*rc` files are located. + +The following example assumes a `~/.zshrc` file. + +```bash +echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc +echo '[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.zshrc +echo 'eval "$(pyenv init -)"' >> ~/.zshrc +``` + +Reload your shell profile in the terminal by running the command: + +```bash +source ~/.zshrc +``` + +Next, proceed to install Python 3.11.5: + +```bash +pyenv install 3.11.5 +``` + + + + + +--- #### Installing `pyenv-virtualenv` @@ -640,6 +699,7 @@ pyenv virtualenv 3.11.5 ss_lite_multi_311 pyenv local ss_lite_multi_311 ``` + #### Executing the Setup To establish a multi-node setup, follow these steps: diff --git a/static/images/Collector-relay.png b/static/images/Collector-relay.png new file mode 100644 index 00000000..1c340e6f Binary files /dev/null and b/static/images/Collector-relay.png differ diff --git a/static/images/Sequencer.png b/static/images/Sequencer.png new file mode 100644 index 00000000..25412c11 Binary files /dev/null and b/static/images/Sequencer.png differ diff --git a/static/images/SequencerRelayNetwork.png b/static/images/SequencerRelayNetwork.png new file mode 100644 index 00000000..fe891706 Binary files /dev/null and b/static/images/SequencerRelayNetwork.png differ diff --git a/static/images/new_architecture_workflow.png b/static/images/new_architecture_workflow.png new file mode 100644 index 00000000..1363f406 Binary files /dev/null and b/static/images/new_architecture_workflow.png differ diff --git a/static/images/protov2-submission-batching.png b/static/images/protov2-submission-batching.png new file mode 100644 index 00000000..8dd8ec4a Binary files /dev/null and b/static/images/protov2-submission-batching.png differ diff --git a/static/images/submission-validation-timeline.png b/static/images/submission-validation-timeline.png new file mode 100644 index 00000000..80d8ef5f Binary files /dev/null and b/static/images/submission-validation-timeline.png differ diff --git a/static/images/validator-resubmission-workflow.png b/static/images/validator-resubmission-workflow.png new file mode 100644 index 00000000..b271919b Binary files /dev/null and b/static/images/validator-resubmission-workflow.png differ diff --git a/static/images/validator-workflow.png b/static/images/validator-workflow.png new file mode 100644 index 00000000..fb5dd8b0 Binary files /dev/null and b/static/images/validator-workflow.png differ