Skip to main content

Portal Loop

Portal Loop is an always-up-to-date staging testnet that allows for using the latest version of Gno, gno.land, and TM2. By utilizing the power of Docker & the tx-archive tool, the Portal Loop can run the latest code from the master branch on the Gno monorepo, while preserving most/all of the previous transaction data.

The Portal Loop allows for quick iteration on the latest version of Gno - without having to make a hard/soft fork.

Below is a diagram demonstrating how the Portal Loop works:

                    +----------------------------------+
| Portal Loop running | < ----+
+----------------------------------+ |
| |
| |
v |
+----------------------------------+ |
| Detect changes in 'master' | |
+----------------------------------+ |
| |
| |
v |
+----------------------------------+ |
| Archive transaction data & state | |
+----------------------------------+ |
| |
| |
v |
+----------------------------------+ |
| Load changes from 'master' | |
+----------------------------------+ |
| |
| |
v |
+----------------------------------+ |
| Replay transaction data | ------+
+----------------------------------+

Specifically, Portal Loop behaves like a normal network until a change is detected in the master branch in the Gno monorepo. At this point, Portal Loop archives on-chain data using the tx-archive tool, saving all transactions that happened on it thus far.

It then pulls the latest changes from the master branch, and inserts all previously archived transactions into the genesis of the newly deployed chain. After genesis has been replayed, the chain continues working as normal.

Using the Portal Loop

The Portal Loop deployment can be found at gno.land, while the exposed RPC endpoints can be found on https://rpc.gno.land:443. The RPC endpoint list can be found in the reference section.

A warning note

While allowing for quick iteration on the most up-to-date software, the Portal Loop has some drawbacks:

  • If a breaking change happens on master, transactions that used the previous version of Gno will fail to be replayed, meaning data will be lost.
  • Since transactions are archived and replayed during genesis, block height & timestamp cannot be relied upon.

Deploying to the Portal Loop

There are two ways to deploy code to the Portal Loop:

  1. automatic - all packages in found in the examples/gno.land/{p,r}/ directory in the Gno monorepo get added to the new genesis each cycle,
  2. permissionless - this includes replayed transactions with addpkg, and new transactions you can issue with gnokey maketx addpkg.

Since the packages in examples/gno.land/{p,r} are deployed first, permissionless deployments get superseded when packages with identical pkgpath get merged into examples/.

The above mechanism is also how the examples/ on the Portal Loop get collaboratively iterated upon, which is its main mission.