GithubHelp home page GithubHelp logo

autonity / docs.autonity.org Goto Github PK

View Code? Open in Web Editor NEW
2.0 8.0 5.0 3.29 MB

Documentation for the Autonity Go Client (AGC)

Home Page: https://docs.autonity.org

SCSS 16.68% HTML 21.54% Shell 3.17% CSS 50.98% Lua 7.64%
autonity documentation

docs.autonity.org's Introduction

Piccadilly Circus Games Competition Website

Getting started

  • Download Quarto
  • Clone this repository
  • In the root
quarto render

Usage:

Migrating from Hugo

For best results, clone into a new directory. However, if you are unable to do that, Delete the following directories as they will conflict and prevent Quarto from building:

 - themes/     # contains docys shortcodes
 - archetypes/ # contains docsy shortcodes
 - layouts/    # contains Markup for docsy templating
 - data/       # is empty and no longer required
 - docs/       # holds the content in a format that works for Hugo (and not Quarto).
 - content/    # holds the content in a format that works for Hugo (and not Quarto). 

Publication workflow

The repo is configured to publish:

Development workflow

  • The master branch will always have the live production version of the website.
  • A hot-fix to the production site is published by creating a branch from master with the hot-fix, and creating a PR. (Once the hot-fix has been merged, master should be merged to develop to ensure that the fix is propagated, and that conflicts are resolved in develop.)
  • The develop branch will always have the WIP next version of the website being prepared.
  • A new version of the production website is published by merging develop into master.

See the repo Wiki Page Git Workflow for when to merge or rebase branches when working on game.autonity.org repo.

Other Piccadilly site resources

For overall site structure, see Autonity Sitemap

Contributing

To contribute to this repo, please raise a pull request as per Github Flow.

Note that in order to maintain a legible Git history, this repo enforces linear history on master. To ensure that your local Git commit log is linear, you should rebase your local changes on top of origin. You can tell Git to do this for this repository by setting the Git option pull.rebase in your local checkout:

git config --local pull.rebase true

Alternatively, you can apply this setting for all your repos by replacing --local with --global.

Reference: Pro Git by Scott Chacon

docs.autonity.org's People

Contributors

cmjc avatar dtebbs avatar flofrie avatar dweng0 avatar lorenzo-dev1 avatar aiman avatar dedenwrg avatar spenot09 avatar noandrea avatar klazomenai avatar szemate avatar raj-shekhar1 avatar rmsams avatar reversesigh avatar

Stargazers

 avatar solostaker.xyz avatar

Watchers

 avatar  avatar  avatar  avatar Geekdom avatar  avatar  avatar Edward Chen avatar

docs.autonity.org's Issues

General documentation feedback

Feedback on running a node

Overall the documentation and explanation of setting up a validator node was brilliant and easy to follow.
Below I have included some of my suggestions and feedback on various aspects of the documentation that I think may further improve the user experience. Thank you!

Installing the Docker image

  1. The docker image location in Step 4. appears to show the location to be ghcr.io/autonity/autonity/autonity:latest whereas the actual location is ghcr.io/autonity/autonity:latest

Run Autonity

  1. Would be nice to include example logs that are expected when in healthy state. This would provide reassurance that the steps are indeed being followed correctly.
  2. Before beginning the sync with the blockchain, a notice recommending a stable internet connection may be beneficial as peer connections may drop otherwise.

Connecting to node

  1. Appears that the example RPC URL is missing the rpc1. prefix in https://NETWORK_NAME.autonity.org . When navigating to the example page of Piccadilly the expected format is https://rpc1.piccadilly.autonity.org/

Registering a Validator

  1. Perhaps guiding readers that when running Docker they have to shell into the running container and run theautonity genEnodeProof --nodekey <NODE_KEY_PATH> <TREASURY_ACCOUNT_ADDRESS> command from there. May not be obvious to all users.

Determining Enode address

  1. The aut cli does not expose the the aut validator compute-address subcommand and returns the following error Error: No such command 'compute-address' (Edit: I was running an older version of aut which was resolved upon update)

Hardware Requirements

  1. The minimum hardware requirements are perhaps overstated (especially for a testnet). Also, once the games begin on Piccadilly, the storage requirements will not be so great as the network will be restarted frequently.
  2. Would be fantastic if there was a feature where current and projected data storage requirments could be observed, in order to allow validator operators to make better hardware decisions.
  3. If there was a "live sync" time that could be seen (i.e. how long it would take a new node to sync the current chain depending on sync mode) that would be immensely useful as I often find myself guessing this (quite inaccurately) with other clients.

Typo on 'Create an account' page

A code block on this page has a typo key-file so does not work.

mkdir keystore
aut account new --key-file ./keystore/alice.key

Corrected:

mkdir keystore
aut account new --keyfile ./keystore/alice.key

Harmonise references to the Autonity CLI tool `autcli`

Describe the bug

There is inconsistent terminology used when referring to the Autonity CLI tool autcli:

  • aut CLI
  • autcli

aut is a command, not the tool name which is Autonity CLI, or autcli after the tool's GitHub repo name https://github.com/autonity/autcli.

To resolve:

  • correct instances of aut CLI -> autcli.
  • rename 'Setup aut CLI' -> 'Setup Autonity CLI'

The "aut CLI" issue occurs on the following pages

% grep -lr '`aut` CLI' .
./content/docs/developer/_index.md
./content/docs/node-operators/connect/_index.md
./content/docs/node-operators/_index.md
./content/docs/delegators/_index.md
./content/docs/delegators/bond-stake/_index.md
./content/docs/concepts/client/_index.md
./content/docs/validators/register-vali/_index.md
./content/docs/validators/_index.md
./content/docs/account-holders/submit-trans-autcli/_index.md
./content/docs/_index.md

To Reproduce

Search for above terms to find the inconsistency.

Device information (please complete the following information):
n/a

Correcting the Sequence of Executions in "How to enroll in Onboard Validator" Guide

Description

Explain the new feature or suggested improvement in as much detail as you can.

As a beginner, I found that the sequence of executions for step 3 in the "How to enroll in Onboard Validator" guide is misleading:
https://game.autonity.org/round-2/on-chain-tasks/onboard-validator/

Currently, the sequence is:

  • aut account sign-message --help
  • aut account import-private-key --help

Following this sequence will lead to errors, as the "sign-message" command expects a private_key file with a string.
As users should first generate the private_key file using "import-private-key" and then use "sign-message".

Who are the expected users of the improvement?

All beginners who are new to the project.

What is the impact of the improvement on the documentation website and its users?

By providing a clearer and more accurate sequence of command executions, users will be able to follow the guide more effectively, reducing potential confusion and errors.

Rationale

Why should this improvement be made? Why is it worthwhile to develop and implement?

The current sequence is misleading, causing users to encounter errors and potentially require additional assistance. Adjusting the sequence to follow the correct workflow will improve the user experience and reduce the likelihood of errors.

Implementation

Do you have ideas regarding the implementation of this feature?

Simply interchanging the sequence of the two commands mentioned in step 3 will enhance the user experience and reduce the likelihood of errors.

Are you willing to implement this feature?

Yes

The maximum amount sent by the faucet is 10ATN

Describe the bug

When I use the Faucet "https://faucet.autonity.org/" indicated in the documentation of Autonity, and I try to send more than 10 ATN the faucet only sends me 10 ATN!!

Either it's a bug in the faucet or it's a limitation that you fixed. But if it's a limit, I think it should be indicated in the websitesite or in the documentation, or display an error message when trying to sending an amount greater than 10 ATN.

Register as a Validator: broken legacy link to `additional helpers`

The page has a broken link to additional helpers entry for jq:

This guide also assumes that the command-line JSON processor jq is available - see additional helpers.

The content was on the original 'How to' home page before restructuring (see: content/docs/howto/_index.md) :

Additional Helpers

In some of the procedures, we will perform commands that will use curl. You may already have curl installed on your system as it comes with many OS distributions.

A good helper for working with JSON response objects returned by RPC is jq (optional).

Register as a validator doesn't use jq in the examples so this link is legacy.

To resolve:

  • Remove broken, legacy link from Register as a validator
  • Consider adding the helpers, perhaps in an alert box type Note?) to Autonity Contract Interface page. Rationale: the RPC examples make use of curl and jq could also be used.

Update Network pages Chain ID values post re-genesis

Describe the edit

There will be a testnet re-genesis before PCGC Round 4 to bring in a protocol upgrade.

In the Networks section the testnet chain ID entries will need to be updated.

Tasks

Testnet Flag ChainID
--bakerloo 65010001
--piccadilly 65100001

Tasks:

AOS - enhance Running an AOS guide to add connecting to an AGC running in a Docker container?

Description

PR #100 adds how to guides for installing and running AOS as a Docker.

An enhancement could be to add an info box on how to connect to an AGC running in Docker - i.e.

  • run docker network ls to get the docker network's running and the NAME
  • run docker network inspect <NAME> to inspect the network and view info on the container running the AGC to get the WS
  • IP address the node is running at
  • specify that WS Address in the docker command for running AOS

Rationale

  • A user running the AOS as Docker may also be running the AGC as Docker

Implementation

  • Add an Info note box with a bullet point list of the steps to get and specify the AGC Docker container's WS Address. See Description above.

Review external links

Description

External links should consistently open in new browser tabs and there should be a visual cue to the reader that the link is to an external site.

Solution

Customise the markdown rendering using Hugo/Docsy customisation techniques to open the page in a new tab and display a glyph indicating external navigation.

There may be other approaches, such as using shortcodes. Example: https://stackoverflow.com/questions/72820972/hugo-how-to-create-a-link-to-page-in-a-shortcode

Rationale

  • visual cue: provides a commonly-used indication that a hyperlink will navigate to an external site
  • open in new tab: to avoid losing local context, it is convenient if an external site opens in another browser tab.

Implementation

Interesting references are:

Update Testnet pages for new `chainID` post re-genesis before PCGC R4

Context
Before R4 of the Piccadilly Circus Games Competition (game.autonity.org) there will be a testnet re-genesis to bring in a protocol upgrade.

The Genesis configuration section of the testnet pages will need to be updated with the new chainID's

Tasks:

Add state transition diagrams for NTN & LNTN

Description

NTN has states too, and they correspond exactly to LNTN states b/c they share the same state transitions. How about displaying this logic visually with a pair of synchronised state machine diagrams:

ntn-state-machine

dot code for reference:

digraph finite_state_machine {
	graph [nodesep=1];
	fontname="Courier-Bold"
	{
	rank=same;
	node [shape = doublecircle, fixedsize=true, width=1.25, height=1.25, xlabel = "NTN"]; unbonded;
	node [shape = circle, fixedsize=true, width=1.25, height=1.25, xlabel=""];
	unbonded -> bonded [label = "bond"];
	bonded -> unbonding [label = "unbond"];
	unbonding -> unbonded;
	}

	{
	style = filled;
	rank=same;
	node [shape = doublecircle, fixedsize=true, width=1.25, height=1.25, label="unminted/\nburned", xlabel = "LNTN"] unminted; 
	node [shape = circle, fixedsize=true, width=1.25, height=1.25, label="locked", xlabel=""] locked; 
	node [shape = circle, fixedsize=true, width=1.25, height=1.25, label="unlocked"] unlocked; 
	unminted -> unlocked [label = "bond"];
	unlocked -> locked [label = "unbond"];
	locked -> unminted;
	}

	unbonded -> unminted [style="invis"];
	bonded -> unlocked [style="invis"];
	unbonding -> locked [style="invis"];

}	

Rationale

Visualisation will improve readability and clarity of the docs. Adding diagrams to the baseline docs is a known To Do not yet actioned.

Tasks

  • Choose digramming language
  • Enable diagramming in website
  • Add state transition diagrams

Reference, Glossary: implement Hugo Taxonomy mechanisms

Description

The glossary is added as a reference page with sub headings and terms linked to these headings from the docs. So, the taxonomy of terms is not structured or formally represented.

The Hugo Taxonomy model mechanism supported by the Docsy theme being used for the site is not being used. Cf. https://www.docsy.dev/docs/adding-content/taxonomy/

Other Docsy sites have developed custom {{ code-templates }} to provide:

  • tool tip showing the term definition during hover
  • term inclusion to pull in the term definition for content reuse (avoiding varying term explanations throughout the docs).

This is a nice-to-have feature.

Rationale

  • Define once and re-use to mitigate risk of duplicate definitions in text
  • Structured representation of glossary terms, i.e. terminology management is implemented using native Hugo Docsy mechanisms
  • Improve UI / UX by having hover text over glossary terms

Implementation

Some nice examples and discussion threads can be found in these projects:

Instructions to launch Autonity via docker-compose?

Description

Suggestion to include a docker-compose file in the docker section of "Run Autonity", instead of / alongside the long command line.

Rationale

Admins will create scripts anyway, but this might provide a slightly easier workflow.

Remove title from nav bar

Description

I believe the title "docs.autonity.org" is unnecessary given it will already be in the url bar, and "documentation" is headlined below.
image

I propose its removal in order to streamline the look and feel of the documentation site
...

Rationale

I believe this will helps to declutter the documentation such that only relevant information is displayed. If users wish to return to the home page, they can click on the logo, which has the same functionality as the title (a clickable link to the home page).

The end result would look something like this:
image

Implementation

Update the navigation.html partial (or add one if not already in place) and remove the title shortcode. I recommend this approach because modifying the title so it is an empty string will result in an empty clickable area.

Out of date link to Web3 Secret Storage Definition

Update Network pages - check page up to date

Description

The Network pages will need to be updated to record:

  • Genesis configuration: oracle symbols and vote period
  • Release: new autonity release version.
  • Faucet: faucet details

Tasks:

  • Bakerloo:
    • Genesis configuration: oracle symbols and vote period
    • Release: new autonity release version
    • Faucet: faucet details
  • Piccadilly:
    • Genesis configuration: oracle symbols and vote period
    • Release: new autonity release version
    • Faucet: faucet details

Lock brownie solc compiler version to v0.8.19

Description

Solc v0.8.20 introduces a new opcode 0x5f that is not supported in v0.10.1 of the autonity client (see here).

Rationale

Locking the compiler version ensure that breaking changes from solc do not affect the existing workflows.

Implementation

This issue can be managed by locking the compiler version to v0.8.19 in the brownie config.

Update Network page Testnet description sections

Description

The distinction of the Piccadilly and Bakerloo Testnets being 'bleeding-edge' and 'stable' is well described on autonity.org/testnets :

Piccadilly is the bleeding-edge public Testnet running the latest deployable version of the Autonity protocol (currently implemented in the Autonity Babylon release of the Autonity client). It is the network used in the pre-MainNet Piccadilly Circus Games. At the end of each game round, validators might re-genesis the network with the latest protocol implementation. If you want to take part in the games and help develop the project, Piccadilly Testnet is your network.

Bakerloo is a stable public Testnet likely running an older version of the Autonity protocol. Bakerloo will re-genesis at least once prior to MainNet launch, but this will be planned and communicated well in advance. If you want to build a project on top of Autonity and need a stable testing environment, Bakerloo is for you.

This is not clearly stated in the Testnet page descriptions on docs.autonity.org: https://docs.autonity.org/networks/testnet-bakerloo/ , https://docs.autonity.org/networks/testnet-piccadilly/

Rationale

The descriptions Testnet purpose should be consistently and clearly stated across websites.

Tasks

Development with Autonity

Context

Autonity Utility Tool aut pre-release v0.1.4 brings in commands for interacting with arbitrary contracts. The Development with Autonity section should be updated to exemplify this.

$ aut --version
aut, version 0.1.4

$ aut contract
Usage: aut contract [OPTIONS] COMMAND [ARGS]...

  Command for interacting with arbitrary contracts.

Options:
  --help  Show this message and exit.

Commands:
  call    Execute a contract call on the connected node, and print the...
  deploy  Deploy a contract, given the compiled JSON file.
  tx      Create a transaction which calls the given contract method,...

Tasks

Reference: Autonity Interfaces, Web3 Namespace: broken and missing links

Describe the bug

In the Autonity Interfaces Reference page Web3 Namespace:

  • the links to supported Geth web3 namespaces are broken.
  • the net namespace is missing.

The Geth docs have been updated and the references have changed:

Namespace From To
admin namespace https://geth.ethereum.org/docs/rpc/ns-admin https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-admin
debug namespace https://geth.ethereum.org/docs/rpc/ns-debug https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-debug
eth namespace https://geth.ethereum.org/docs/rpc/ns-eth https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-eth
net namespace https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-net
personal namespace https://geth.ethereum.org/docs/rpc/ns-personal https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-personal
txpool namespace https://geth.ethereum.org/docs/rpc/ns-txpool https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool

Tasks

  • correct links to supported Geth web3 namespaces are broken.
  • add missing link to the net namespace.

Correct Auton symbol

Describe the bug

The auton symbol is out of date and requires editing to 'ATN'.

Tasks

Update instances of symbol in pages:

  • Fund an account
  • Bakerloo Network
  • Piccadilly Network

Provide feedback on the website itself

While browsing the Ethereum documentation (e.g. https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) I noticed that they have a little button in the bottom-right corner that allows to compile a quick form to give feedback on the documentation website.

I think it would be useful to have it on our docs website as well in the future. It allows to capture feedback in a more broad way wrt what can be captured with github issues (e.g. the form asks to rate the usefulness of the information, its complexity, etc.)

The delay of "Change validator commission rate Delay" of "Autonity Utility Tool (aut)" is not noted in the documentation

I try to change the commission rate of my validator using the aut function aut validator change-commission-rate --validator , but the the change was only processed after several hours.

Problem: In the documentaion you don't note this delay!
Proposal : I Think this delay should be noted as it is made for the function aut validator bond --validator, it is noted "Bonding requests are not processed until the end of the current epoch. ..."

Register validator - update to use new `validator register` in `v0.3.0-dev` `aut` release

Context

Changes to register Validator signature to add oracle as an argument mean the v0.2.0 aut aut register validator function was broken. The docs in the develop branch therefore use aut contract tx and ABI as the example in the Valdiators, Register a Validator step.

Aut https://github.com/autonity/aut/releases/tag/v0.3.0.dev0 supports the new signature. The docs how to can be updated to use aut validator register again..

Task

Edit in develop http://localhost:1313/validators/register-vali/#step-3-submit-the-registration-transaction

  • to use aut validator register.

Node operators: add note clarifying node migration

Description

The node operators section states how to install and run a node, but does not give any information on how to migrate a node. This can be clarified by a simple note.

Tasks

  • Node operators, Run Autonity. Add note on node migration. If migrating a node to a new instance: the nodekey and ip address needs to be maintained to keep the same node identifier address and enode url.

Error in Reference genesis

Describe the bug

The entry for treasuryFee does not who the correct number of 0's for 10^18 in the example, and neither does the example genesis.json.

Tasks to resolve:

Device information (please complete the following information):

  • Device: Desktop
  • OS: Mac OS Ventura 13.0.1
  • Browser Chrome
  • Browser Version 108.0.5359.124 (Official Build) (x86_64)

Networks, add rate limiting on public RPC endpoints

Description

The networks section does not provide information on rate limiting applied to the Bakerloo and Piccadilly public RPC endpoints. operators section states how to install and run a node, but does not give any information on how to migrate a node. This can be clarified by a simple note.

Tasks

Configure privacy friendly Plausible Analytics service

Description

To use site-analytics data, configure the simple, privacy friendly Plausible Analytics service for this site.
This feature has on impact on current and future users.

Brief Description of Plausible:

Plausible Analytics is a privacy-first web analytics tool. It is built to be compliant with the different privacy regulations, such as GDPR and CCPA. Plausible doesn’t use cookies and doesn’t collect any personal data whatsoever.
If you’re not collecting or processing any personal data and if you’re not using cookies, you may not legally need a privacy policy for your use of Plausible Analytics.

Rationale

To help understand services usage and to help improve them, automatically receive information about user interactions, like the pages or other content view and the dates and times of user visits

Implementation

https://plausible.io/docs/hugo-integration

Incorrect Docker image url

Description

The Docker image url in the docs is wrong. It has an additional autonity in its path. It needs to be modified as follows: ghcr.io/autonity/autonity/autonity:latest -> ghcr.io/autonity/autonity:latest.
The first (incorrect) url causes the docker pull process to fail with: Error response from daemon: manifest unknown

This is visible at the following urls:

Check and update How to Guide example commands are up to date with new AGC features and `aut` `0.3.0-dev` Release

Context
Review the How to Guides and ensure they are all up to sync with:

  • latest feature changes
  • latest aut CLI release 0.3.0-dev

For example,

aut node info is fine.

aut validator info needs updating in https://docs.autonity.org/delegators/bond-stake/#discover-registered-validators as the response has changed.

Tasks

Check examples are current in How to Guide sections:

  • Accounts
  • Staking
  • Running a node
  • Running a validator
  • Running an oracle server
  • Development

Legacy Ethereum concepts in Autonity?

Documentation includes some legacy Ethereum concepts (related to PoW) that don't apply to Autonity, yet still exist for compatibility with upstream or other reasons.

There are inconsistencies in the documentation of these legacy concepts:

Tasks

  • Address inconsistency in the example: correct some of the descriptions in https://docs.autonity.org/concepts/system-model/#block-header, where the docs give the impression that these fields are used in autonity protocol as described.
  • Review the system model and reference/genesis sections to discover other inconsistencies if any.

Add Versioning to docs site for next release

As an Autonity docs site user
I want to access versions of documentation for current and previous releases of the client
So that I can read documentation for the client version I am using.

Tasks:

  • Add Docsy Theme versioning to toml.config.

References

Restructuring

Description

We've discussed re-organising into a setion per "role" or "participant type", which I think we agree on.
We might also consider further re-ordering, so that the "guide" content comes first, and the deeper architecture stuff comes later.

My reasoning is that many of these pages actually go quite deep into the mechanisms (which is actually great - I find it very frustrating when a new chain doesn't make these details readily available), but a large fraction of the audience are going to want to know the high-level roles (Account holder, delegator, node operator, validator), determine which one they want to take on, and dive right in.

There is some high-level info that needs to be made clear up front, but I think this is basically the current "Autonity" top-level page.

So I'm suggesting a restructure that's something like:

     - [ ] [10] "Overview" (current content of the Autonity section page -
       mention the high-level tech points, and focus on the
       participant roles: Account Holder, Delegator, Operator, Validator.  See "architecture" (below) for details.)
     - [ ] [20] "Account Holder"
       - Setup AUT cli
       - Create an account
       - Fund an account (combine with the above page?)
       - Submit a transaction (and make queries)
     - [ ] [30] "Delegator"
       - Bond
       - Unbond
       - Claim rewards
       - Transfer LNTN
     - [ ] [40] "Operator"
       - Install Autonity
       - Run Autonity
       - Setup Node Monitoring
     - [ ] [50] "Validator"
       - Register
       - Pause
       - Reactivate
       - Change commission rate
     - [ ] [60] "Developer"  (Hidden, whatever is left howtos)
     - [ ] [70] "Networks"
     - [ ] [80] "Concepts" (use content from current "Architecture")
       - ... all the pages currently under "Autonity"
     - [ ] [90] "Reference"
       - as-is
     - [ ] [100] "Glossary"
       - as-is
     - [ ] [110] "Known Issues"
       - as-is

Implementation

  • update the front page to link to top-level sections
  • "key concepts" from "Node Operators" into "Overvew"
    • Newton
    • (Liquid) Staking - cover Liquid Newton
    • paticipant node
    • validator node
    • consensus committee
  • link to networks from overview

Update docs for change of `snap` to `aut-snap`

Description

The snap protocol is being renamed from snap to aut-snap by autonity/autonity#805. This addresses issue autonity/autonity#791, which is logged in the docs.autonity.org site as a Known issue at: https://docs.autonity.org/issues/#error-snapshot-extension-registration-failed.

Note that the --syncmode flag option snap is not renamed and no other change is needed in the docs for this.

Tasks

Move lifecycle information details from `Protocol primitives` to `Accountability Event Lifecycle`

As of now the sections under protocol primitives contain details about the lifecycle of the primitive. We should shorten these paragraphs so that they contain just a description of the primitive, and move lifecycle details to Accountability Event Lifecycle.

The Accountability Event Lifecycle would also be the right place to add some diagrams (e.g. misbehavior flow, accusation flow, jailing flow)

Originally posted by @lorenzo-dev1 in #81 (comment)

Blank entries in Piccadilly and Bakerloo genesis configuration tables

The corresponding values for genesis configuration fields:

  • config.autonity.operator
  • config.autonity.treasury  
  • config.autonity.validators  

are currently blank in the corresponding genesis configuration pages for Piccadilly and Bakerloo.

I believe the values should not be blank, but rather they are simply missing from the table. So the table is incomplete.

Moreover, this looks visually jarring.

I would suggest either removing the entries (with explanation?) or completing the data in the tables.

See:

  • content/docs/networks/testnet-bakerloo/_index.md
  • content/docs/networks/testnet-piccadilly/_index.md

Known issues: add issue for Non-autonity nodes trying to connect

Context

Non-Autonity nodes trying to connect with Autonity nodes, as described in autonity/autonity#791

This results in error messages being displayed to Terminal when running the node

Tasks

References

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.