Zenon Developer Docs

Development
1

I have been working on developer docs with the goal of moving them to https://docs.zenon.network within the next 60 days. The current DRAFT of the docs can be found here: https://docs.0x3639.com/

I know @aliencoder has an approved AZ for this work but he is very busy with Supernova and the BTC Bridge work. We need to step up and help get the docs done. Anyone with AI and some extra time can help audit and write docs. Not every page is technical.

I would like for this to be a community effort. Anyone in the community can write pages or review (proofread / correct) draft pages. We can track our contributions on this page with the goal of allocating the AZ according to the work summary.

On March 1, 2025 we can make the docs live and manage them from the zenon-network repo going forward. Over the next 60 days I plan to work on the docs every day and post my additions for review or comment. You can either comment here in the chat or submit a PR directly in my repo to suggest changes. If you want to ask for an allocation of the AZ for the work, please update the contribution page.

2 Likes
2

DRAFT pages that are ready for review & comment. I’ve been moving quickly focusing on getting as much work done as possible. So I expect there are errors. Please help me find them.

Social Share Image - thank you @Stark

image
image1200Ă—675 93.7 KB

1 Like
3

I updated the Getting Started article. I styled it some and added some links.

Feedback welcome.

4

@georgezgeorgez @MoonBaze @digitalSloth @CryptoFish

Would you guys mind reviewing this page on SDK Status? It will take just a minute or two.

I would like to add a comment on what is missing. For example @digitalSloth I think PHP is missing PoW for TXs? If you can add a quick response for the SDK you cover I can add a comment and if you need help will mention that.

5

The PHP SDK is missing keystore support due to an issue with the PHP implementation of argon2 not supporting parallelism - About parallelism (of Argon2) in the password hashing API · jedisct1/libsodium · Discussion #1092 · GitHub Help wanted on this if anyone knows a solution.

Signing/sending transactions is still a work in progress too but Im hoping to have more time to look at this again soon

1 Like
6

I wanted to share an idea to improve how we track the progress of our SDK implementations. Instead of using a single completion percentage, which can make it seem like the SDK isn’t fully ready, we can break things down by functionality.

Each functionality would have its own progress percentage, showing what’s fully implemented, what’s still in progress, and what hasn’t started yet. This should give a much clearer picture of where things stand.

To make things consistent, this template can serve as a standardized method for tracking SDK progress. Every maintainer would be responsible for maintaining and updating this status in their respective repository. This ensures the status of each implementation is transparent and accessible to everyone.

Additionally, by standardizing the format and location of this status file, we could enable our documentation system to automatically scan through the list of repositories and retrieve the status directly from a specific file. This would streamline the process of keeping documentation up-to-date and provide a centralized overview of all implementations.

Here’s an example of the proposed format:

SDK Status Template

  • SDK Name: [SDK Name]
  • Repository URL: [Repository Link]
  • Maintainer: [Maintainer Name]
Functionality Status
ABI Encoding Completed
ABI Decoding Completed
Argon2 Completed
Ed25519 Completed
Bip32 In progress
Wallet In progress
PoW Not started
Ledger API Completed
Stats API Completed
Accelerator API Completed
Bridge API Completed
Htlc API Completed
Liquidity API Completed
Pillar API Completed
Plasma API Completed
Sentinel API Completed
Spork API Completed
Stake API Completed
Swap API Completed
Token API Completed
Unit tests In progress
Documentation In progress

By adopting this approach, maintainers can easily share the current status of their SDKs, and our documentation system can ensure that this information is always up-to-date and centralized.

Let me know your thoughts or if there’s anything we should tweak to make this even better!

7

great idea. thanks for suggesting this. This make a lot of sense to me. Let me look into how to accomplish what you proposed with the docs.

8

This basically boils down to creating a boilerplate template for SDK implementations. We could start by setting up a repository for this. I’m thinking to use a Json file for the status information and try to automatically process it in the docs.

Create a Central Boilerplate Repository

  • This repository serves as the starting point for all SDK implementations.
  • Include the necessary folders and files (e.g., README.md, CONTRIBUTING.md, etc.) to ensure consistency across all implementations.

Add a Standardized JSON File for Status Tracking

  • Define a file (e.g., status.json) that every SDK implementation must include in the root directory.
  • Example structure of the status.json file:
{
  "name": "Example SDK",
  "repository_url": "https://example.com/repo",
  "maintainers": [ "John Doe" ],
  "functionalities": [
    {
      "name": "ABI",
      "status": 100,
      "notes": "Completed"
    },
    {
      "name": "Wallet",
      "status": 75,
      "notes": "Partially implemented, missing wallet manager"
    },
    {
      "name": "Bridge API",
      "status": 0,
      "notes": "Not started"
    }
  ]
}

Automate Processing in Documentation

  • Write a script/tool that scans all SDK repositories in a predefined list.
  • The script can locate and parse the status.json file in each repository and generate an aggregated status overview in the central documentation.

Include Boilerplate Guidelines

  • Provide clear instructions in the boilerplate repository on how to structure SDKs and maintain the status.json file.
  • Mention that maintainers are responsible for keeping this file updated.
1 Like
9

I can parse the json into the docs and can create a script to pull in the status.json from other repos.

How can we standardize the README.md for all the SDKs if they will each be different? Or is this a README.md that describes the status.json only?

Are you thinking we create a repo in /zenon-network that is something like /sdk-status? In that repo we have the README.md, CONTRIBUTING.md, and config.json which explain how each SDK needs to include these files? The confg.json will have the full structure (provided above) for each SDK author to maintain? We would ask each SDK dev to keep the config.json up to date and we can scrape that data every day and pull into docs if anything changes?

10

I updated the Getting Started page. Please take a look and LMK if you have any comments / suggestions.

11

Specs are ready for review.

They were reproduced from this source docs
https://wiki.zenon.network/#!index.md

12

Consensus is updated and ready for review. I received some feedback from TG to make it simple and generic. I have done that. I also discuss the transition to Phase I by introducing N&T with a generic definition.

13

Yes the main plan is to create a repository, probably called /sdk-boilerplate, that acts as a starting point or template for all SDKs. This repo would include some key files:

  1. README.md: A guide for developers that explains what the SDK needs, with examples they can use or adapt.
  2. CONTRIBUTING.md: A file with instructions on how to contribute or keep things consistent.
  3. A metadata file: This would define important details about the SDK. Developers would be responsible for keeping this file up to date.

A script or tool would regularly check these metadata files from all the SDKs, gather the info, and automatically update central docs whenever something changes.

I’m leaning towards calling the repo /sdk-boilerplate instead of /sdk-status, because it’s more flexible and leaves room to add extra tools or resources in the future, like linting tools, CI/CD templates, or testing guidelines.

Concerning the config.json file name. I’d go with sdk-metadata.json or metadata.json because it’s clear, specific to SDKs, and flexible enough for future changes. If the file is more about settings than descriptive info, then config.json could be a good second option.

14

Nice, gonna get time to check on detail.

1 Like
15

Official Links updated & fixed.

2 Likes
16

Nice work! Succinct and easier. Are you interested into being aid in some specific tasks? I’m willing to help but IDK where.

17

was thinking about a light-syrius version - it’s taking a while to sync - doesn’t makes any sense to wait that long for transacting - what about sharding the syncing or somthin

18

Mr. Kaine has discussed integrating zerosync for IBD. Near instant sync. You can see a demo here: ZeroSync | Header Chain Verifier

1 Like
19

Here’s a discussion you might appreciate:

1 Like