Network | RPC Endpoint | Chain ID |
---|---|---|
Portal Loop | https://rpc.gno.land:443 | portal-loop |
Test5 | https://rpc.test5.gno.land:443 | test5 |
All networks follow the same pattern for websocket connections:
wss://<rpc-endpoint:port>/websocket
XXX: tell that portal loop is currently using a custom code but will switch to a gnodev powered alternative, usable by anyone to run a staging
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 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.
The Portal Loop deployment can be found at gno.land, while
the exposed RPC endpoints can be found on https://rpc.gno.land:443
.
XXX: list or link to the list of available RPC endpoints.
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.
There are two ways to deploy code to the Portal Loop:
- 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, - permissionless - this includes replayed transactions with
addpkg
, and new transactions you can issue withgnokey 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.
gno.land testnets are categorized by 4 main points:
- Persistence of state
- Is the state and transaction history persisted?
- Timeliness of code
- How up-to-date are Gno language features and demo packages & realms?
- Intended purpose
- When should this testnet be used?
- Versioning strategy
- How is this testnet versioned?
Below you can find a breakdown of each existing testnet by these categories.
Portal Loop is an always up-to-date rolling testnet. It is meant to be used as
a nightly build of the Gno tech stack. The home page of gno.land
is the gnoweb
render of the Portal Loop testnet.
- Persistence of state:
- State is kept on a best-effort basis
- Transactions that are affected by breaking changes will be discarded
- Timeliness of code:
- Packages & realms which are available in the
examples/
folder on the Gno monorepo exist on the Portal Loop in matching state - they are refreshed with every new commit to themaster
branch.
- Packages & realms which are available in the
- Intended purpose
- Providing access the latest version of Gno for fast development & demoing
- Versioning strategy:
- Portal Loop infrastructure is managed within the
misc/loop
folder in the monorepo
- Portal Loop infrastructure is managed within the
Test5 a permanent multi-node testnet. It bumped the validator set from 7 to 17 nodes, introduced GovDAO V2, and added lots of bug fixes and quality of life improvements.
Test5 was launched in November 2024.
- Persistence of state:
- State is fully persisted unless there are breaking changes in a new release, where persistence partly depends on implementing a migration strategy
- Timeliness of code:
- Pre-deployed packages and realms are at monorepo commit 2e9f5ce
- Intended purpose
- Running a full node, testing validator coordination, deploying stable Gno dApps, creating tools that require persisted state & transaction history
- Versioning strategy:
- Test5 is to be release-based, following releases of the Gno tech stack.
These testnets are deprecated and currently serve as archives of previous progress.
Test4 is the first permanent multi-node testnet. Archived data for test4 can be found here.
Launch date: July 10th 2024 Release commit: 194903d
The third Gno testnet. Archived data for test3 can be found here.
Launch date: November 4th 2022 Release commit: 1ca2d97
The second Gno testnet. Find archive data here.
Launch date: July 10th 2022 Release commit: 652dc7a
The first Gno testnet. Find archive data here.
Launch date: May 6th 2022 Release commit: 797c7a1