From 3dd8b00bc65c42c59014e9f9e905a0baadfc5af4 Mon Sep 17 00:00:00 2001 From: Tobias Date: Thu, 14 May 2026 10:57:22 -0400 Subject: [PATCH 1/3] Bootstrap public TelosZero main docs --- .github/CODEOWNERS | 1 + CONTRIBUTING.md | 39 +++ GOVERNANCE.md | 51 ++++ LEGAL.md | 45 +++ MAINTAINERS.md | 30 ++ PATCHES.md | 26 ++ README.md | 263 ++++++++---------- SECURITY.md | 25 ++ SUPPORT.md | 26 ++ genesis/README.md | 24 +- genesis/jungle_chain_id.json | 3 - genesis/jungle_genesis.json | 24 -- genesis/kylin_chain_id.json | 3 - genesis/telos_mainnet_chain_id.json | 3 + ...enesis.json => telos_mainnet_genesis.json} | 31 ++- genesis/telos_testnet_chain_id.json | 3 + ...enesis.json => telos_testnet_genesis.json} | 6 +- genesis/vaulta_chain_id.json | 3 - 18 files changed, 393 insertions(+), 213 deletions(-) create mode 100644 .github/CODEOWNERS create mode 100644 CONTRIBUTING.md create mode 100644 GOVERNANCE.md create mode 100644 LEGAL.md create mode 100644 MAINTAINERS.md create mode 100644 PATCHES.md create mode 100644 SECURITY.md create mode 100644 SUPPORT.md delete mode 100644 genesis/jungle_chain_id.json delete mode 100644 genesis/jungle_genesis.json delete mode 100644 genesis/kylin_chain_id.json create mode 100644 genesis/telos_mainnet_chain_id.json rename genesis/{kylin_genesis.json => telos_mainnet_genesis.json} (63%) create mode 100644 genesis/telos_testnet_chain_id.json rename genesis/{vaulta_genesis.json => telos_testnet_genesis.json} (80%) delete mode 100644 genesis/vaulta_chain_id.json diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 0000000000..f0c31a3aaf --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1 @@ +* @telosnetwork/telos-core-devs diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000000..75db28d2fa --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,39 @@ +# Contributing + +Contributions should go through pull requests against `main` or a documented +release branch. + +## Development Rules + +- Keep changes narrowly scoped. +- Preserve upstream attribution when incorporating external patches. +- Do not make consensus or storage-format changes without a design note. +- Keep `nodeos`, `cleos`, and `keosd` compatibility unless a release plan says + otherwise. +- Update packaging and operator docs when behavior affects installation, + upgrades, or runtime configuration. + +## Commit And PR Expectations + +Pull requests should include: + +- a short summary +- compatibility impact +- tests run +- upstream or Community Edition references, if any + +For backports or incorporated upstream patches, include the source commit or PR +URL in the PR description. + +## Local Verification + +At minimum, run syntax checks before opening a PR when touching the relevant +files: + +```bash +bash -n tools/tweak-deb.sh +sh -n scripts/postinst +sh -n scripts/prerm +perl -c tools/pinned.pl +python3 -m py_compile tests/TestHarness/Node.py tests/TestHarness/queries.py tests/TestHarness/testUtils.py tests/cli_test.py +``` diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 0000000000..e8b5b45460 --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,51 @@ +# Governance + +TelosZero Core is maintained under the TelosNetwork GitHub organization. + +## Project Stewardship + +Maintainers should prioritize: + +- preserving upstream history and attribution +- keeping runtime behavior compatible unless a change is explicitly reviewed as + a protocol change +- documenting licensing, patch, build, and release provenance +- replacing inherited CI, release, and signing infrastructure with Telos-owned + equivalents +- publishing clear operator guidance for every production release + +## Maintainer Authority + +Maintainers are responsible for reviewing code, release artifacts, security +updates, and public communications. No single maintainer should be the only +person able to merge, release, or administer the repository. + +The initial code owner team is `@telosnetwork/telos-core-devs`. + +## Branch Policy + +`main` is the development branch and should not be used directly in production. + +Production release branches use the `release/*-teloszero` naming pattern. +Release branches require: + +- a documented release plan +- passing CI for build and test targets selected for that release +- maintainer approval +- documented artifact integrity checks +- upgrade and rollback notes for node operators + +## Protocol Changes + +Consensus, serialization, database format, protocol feature, and network +compatibility changes require an explicit design note before implementation. +The design note should state expected compatibility, activation requirements, +test coverage, and operator impact. + +## Upstream And Community Edition Changes + +`AntelopeIO/spring` is tracked as `upstream`. Spring Community Edition may be +tracked as `ce` as a reference source for legal/process cues and useful +patches. Changes from either source should be reviewed and merged +intentionally; bulk imports should be avoided unless they are part of a +documented release sync. diff --git a/LEGAL.md b/LEGAL.md new file mode 100644 index 0000000000..0bace4807d --- /dev/null +++ b/LEGAL.md @@ -0,0 +1,45 @@ +# Legal And Licensing Notes + +This repository is the TelosNetwork-maintained continuation of +`AntelopeIO/spring`. + +## License Provenance + +The repository includes the upstream Spring `main` license update commit that +changed Spring to MIT terms: + +```text +e6a99f68b67abc4d89fe716755b2e1394a4991f7 +``` + +Existing upstream copyright notices are preserved. + +## Stable 1.2 Release Line + +The TelosZero stable 1.2 release branch is based on upstream Spring `v1.2.2`: + +```text +04bdb089edc790507d96ff52f41cc781fb3fa0f3 +``` + +That branch carries TelosZero release packaging, Telos genesis materials, and a +documented set of selected post-1.2.2 Spring fixes. + +## Older Branches And Tags + +Historical Spring branches and tags are preserved for auditability. Some older +release branches and tags may contain different license terms. TelosZero +production binaries should be published only from branches whose base and +license provenance are documented. + +## Community Edition + +Spring Community Edition may be used as a reference source for process cues and +candidate patches. TelosZero Core does not inherit Community Edition package +renames or release tags unless maintainers explicitly merge those changes. + +## Trademarks + +TelosZero maintainers should avoid implying endorsement by upstream Spring, +AntelopeIO, EOS Network Foundation, Vaulta Foundation, or other projects unless +that endorsement has been explicitly granted. diff --git a/MAINTAINERS.md b/MAINTAINERS.md new file mode 100644 index 0000000000..2b97f83531 --- /dev/null +++ b/MAINTAINERS.md @@ -0,0 +1,30 @@ +# Maintainers + +Initial code ownership is assigned to: + +- `@telosnetwork/telos-core-devs` + +## Maintainer Expectations + +Maintainers should: + +- review protocol-affecting changes with extra care +- preserve attribution when incorporating upstream Spring or Community Edition + work +- keep package and release provenance clear +- avoid force-pushing shared branches +- use pull requests for changes intended for `main` or release branches +- keep branch protection, release access, and security reporting monitored + +## Release Roles + +Each production release should identify: + +- release owner +- build/reproducibility verifier +- test verifier +- security reviewer +- operator communications owner + +Release signing keys and recovery procedures should be documented before +TelosZero release artifacts are described as signed. diff --git a/PATCHES.md b/PATCHES.md new file mode 100644 index 0000000000..dd9c580834 --- /dev/null +++ b/PATCHES.md @@ -0,0 +1,26 @@ +# Patch Provenance + +This file records notable upstream Spring or Spring Community Edition patches +incorporated by TelosZero maintainers outside of normal upstream merges. + +## Stable 1.2 Release Line + +The TelosZero `release/1.2-teloszero` branch incorporates selected post-1.2.2 +Spring fixes for reproducibility, build compatibility, test stability, and +runtime stability. The release branch remains the authoritative source for the +exact commits included in the `teloszero-v1.2.2` release. + +Meaningful upstream patch sources for that release include: + +- AntelopeIO/spring#1742 - initialize the atomic `timer_state_t` +- AntelopeIO/spring#1841 - validate the pinned Debian package repository +- AntelopeIO/spring#1845 - validate LLVM and CMake tarball hashes +- AntelopeIO/spring#1873 - improve block/producer-round test logic +- AntelopeIO/spring#1875 - avoid undefined behavior in WASM injection +- AntelopeIO/spring#1876 - wait for block 2 in CLI tests +- AntelopeIO/spring#1877 - support multi-threaded subprocess log writes +- AntelopeIO/spring#1879 - signal block processing if sync is interrupted +- AntelopeIO/spring#1881 - avoid OC interrupts during replay + +Larger behavior changes should be reviewed in their own TelosZero pull requests +before landing on `main` or a release branch. diff --git a/README.md b/README.md index 3ebe2c7268..61dd82a95c 100644 --- a/README.md +++ b/README.md @@ -1,59 +1,80 @@ -# Spring +# TelosZero Core -1. [Branches](#branches) -2. [Supported Operating Systems](#supported-operating-systems) -3. [Binary Installation](#binary-installation) -4. [Build and Install from Source](#build-and-install-from-source) -5. [Bash Autocomplete](#bash-autocomplete) +**The Telos protocol stack has a home again.** -Spring is a C++ implementation of the [Antelope](https://github.com/AntelopeIO) protocol with support for Savanna consensus. It contains blockchain node software and supporting tools for developers and node operators. +TelosZero Core is the TelosNetwork-maintained continuation of Antelope Spring: +a focused, Telos-owned chain software line for operators, infrastructure +providers, exchanges, tooling teams, and protocol contributors who need a +serious production path forward. -## Branches -The `main` branch is the development branch; do not use it for production. Refer to the [release page](https://github.com/AntelopeIO/spring/releases) for current information on releases, pre-releases, and obsolete releases, as well as the corresponding tags for those releases. +This is not a casual rename. TelosZero keeps the battle-tested Spring runtime +surface, preserves the history that matters, and moves release authority, +packaging, provenance, and long-term maintenance into Telos hands. -## Supported Operating Systems -We currently support the following operating systems. -- Ubuntu 22.04 Jammy -- Ubuntu 20.04 Focal +The runtime command names remain stable: `nodeos`, `cleos`, `keosd`, and +`spring-util`. -Other Unix derivatives such as macOS are tended to on a best-effort basis and may not be full featured. If you aren't using Ubuntu, please visit the "[Build Unsupported OS](./docs/00_install/01_build-from-source/00_build-unsupported-os.md)" page to explore your options. +## Status And Branches -If you are running an unsupported Ubuntu derivative, such as Linux Mint, you can find the version of Ubuntu your distribution was based on by using this command: -```bash -cat /etc/upstream-release/lsb-release -``` -Your best bet is to follow the instructions for your Ubuntu base, but we make no guarantees. +`main` is the TelosZero Core development branch. Do not run `main` directly in +production. + +Production operators should use tagged releases from maintained release +branches. The first public TelosZero release line is: + +- `release/1.2-teloszero` for the conservative 1.2 production line based on + Antelope Spring `v1.2.2` + +The initial public release is +[`teloszero-v1.2.2`](https://github.com/telosnetwork/teloszero-core/releases/tag/teloszero-v1.2.2). + +TelosZero exists to make Telos infrastructure boring in the best possible way: +owned, reviewable, reproducible, and maintained. ## Binary Installation -This is the fastest way to get started. From the [latest release](https://github.com/AntelopeIO/spring/releases/latest) page, download a binary for one of our [supported operating systems](#supported-operating-systems), or visit the [release tags](https://github.com/AntelopeIO/spring/releases) page to download a binary for a specific version of Spring. -Once you have a `*.deb` file downloaded for your version of Ubuntu, you can install it as follows: +Download the operator package from the +[latest TelosZero Core release](https://github.com/telosnetwork/teloszero-core/releases/latest). + +For `teloszero-v1.2.2`, the public operator artifact is: + +```text +teloszero-core_1.2.2_amd64.deb +``` + +Install the downloaded package on a supported Ubuntu host: + ```bash sudo apt-get update -sudo apt-get install -y ~/Downloads/spring*.deb +sudo apt-get install -y ~/Downloads/teloszero-core_*.deb ``` -Your download path may vary. If you are in an Ubuntu docker container, omit `sudo` because you run as `root` by default. -Finally, verify Spring was installed correctly: +Your download path may vary. If you are in an Ubuntu container, omit `sudo` +because you run as `root`. + +Verify the install: + ```bash nodeos --full-version ``` -You should see a [semantic version](https://semver.org) string followed by a `git` commit hash with no errors. For example: -``` -v1.0.1-9026a03c09c9b4f93edca696b5eef259f0ab96b3 -``` -## Build and Install from Source -You can also build and install Spring from source. +## Supported Operating Systems + +TelosZero Core supports the same primary operating systems inherited from the +Spring line unless a release note says otherwise: + +- Ubuntu 22.04 Jammy +- Ubuntu 20.04 Focal -### Prerequisites -You will need to build on a [supported operating system](#supported-operating-systems). +Other Unix-like systems, including macOS, are best-effort only. + +## Build From Source + +Requirements: -Requirements to build: - C++20 compiler and standard library - CMake 3.16+ -- LLVM 7 - 11 - for Linux only - - newer versions do not work +- LLVM 7 through 11 for Linux OC builds - libcurl 7.40.0+ - git - GMP @@ -61,164 +82,102 @@ Requirements to build: - python3-numpy - zlib -### Step 1 - Clone -If you don't have the Spring repo cloned to your computer yet, [open a terminal](https://itsfoss.com/open-terminal-ubuntu) and navigate to the folder where you want to clone the Spring repository: -```bash -cd ~/Downloads -``` -Clone Spring using either HTTPS... -```bash -git clone --recursive https://github.com/AntelopeIO/spring.git -``` -...or SSH: -```bash -git clone --recursive git@github.com:AntelopeIO/spring.git -``` - -> ℹ️ **HTTPS vs. SSH Clone** ℹ️ -Both an HTTPS or SSH git clone will yield the same result - a folder named `spring` containing our source code. It doesn't matter which type you use. +Clone with submodules: -Navigate into that folder: ```bash -cd spring +git clone --recursive https://github.com/TelosNetwork/teloszero-core.git +cd teloszero-core ``` -### Step 2 - Checkout Release Tag or Branch -Choose which [release](https://github.com/AntelopeIO/spring/releases) or [branch](#branches) you would like to build, then check it out. If you are not sure, use the [latest release](https://github.com/AntelopeIO/spring/releases/latest). For example, if you want to build release 1.0.1 then you would check it out using its tag, `v1.0.1`. In the example below, replace `v0.0.0` with your selected release tag accordingly: -```bash -git fetch --all --tags -git checkout v0.0.0 -``` +Install build dependencies on Ubuntu 22.04: -Once you are on the branch or release tag you want to build, make sure everything is up-to-date: -```bash -git pull -git submodule update --init --recursive -``` - -### Step 3 - Build -Select build instructions below for a [pinned build](#pinned-build) (preferred) or an [unpinned build](#unpinned-build). - -> ℹ️ **Pinned vs. Unpinned Build** ℹ️ -We have two types of builds for Spring: "pinned" and "unpinned." A pinned build is a reproducible build with the build environment and dependency versions fixed by the development team. In contrast, unpinned builds use the dependency versions provided by the build platform. Unpinned builds tend to be quicker because the pinned build environment must be built from scratch. Pinned builds, in addition to being reproducible, ensure the compiler remains the same between builds of different Spring major versions. Spring requires the compiler version to remain the same, otherwise its state might need to be recovered from a portable snapshot or the chain needs to be replayed. - -> ⚠️ **A Warning On Parallel Compilation Jobs (`-j` flag)** ⚠️ -When building C/C++ software, often the build is performed in parallel via a command such as `make -j "$(nproc)"` which uses all available CPU threads. However, be aware that some compilation units (`*.cpp` files) in Spring will consume nearly 4GB of memory. Failures due to memory exhaustion will typically, but not always, manifest as compiler crashes. Using all available CPU threads may also prevent you from doing other things on your computer during compilation. For these reasons, consider reducing this value. - -> 🐋 **Docker and `sudo`** 🐋 -If you are in an Ubuntu docker container, omit `sudo` from all commands because you run as `root` by default. Most other docker containers also exclude `sudo`, especially Debian-family containers. If your shell prompt is a hash tag (`#`), omit `sudo`. - -#### Pinned Reproducible Build -The pinned reproducible build requires Docker. Make sure you are in the root of the `spring` repo and then run -```bash -DOCKER_BUILDKIT=1 docker build -f tools/reproducible.Dockerfile -o . . -``` -This command will take a substantial amount of time because a toolchain is built from scratch. Upon completion, the current directory will contain a built `.deb` and `.tar.gz` (you can change the `-o .` argument to place the output in a different directory). If needing to reduce the number of parallel jobs as warned above, run the command as, -```bash -DOCKER_BUILDKIT=1 docker build --build-arg SPRING_BUILD_JOBS=4 -f tools/reproducible.Dockerfile -o . . -``` - -#### Unpinned Build -The following instructions are valid for this branch. Other release branches may have different requirements, so ensure you follow the directions in the branch or release you intend to build. If you are in an Ubuntu docker container, omit `sudo` because you run as `root` by default. - -Install dependencies: ```bash sudo apt-get update sudo apt-get install -y \ - build-essential \ - cmake \ - git \ - libcurl4-openssl-dev \ - libgmp-dev \ - llvm-11-dev \ - python3-numpy \ - file \ - zlib1g-dev + build-essential \ + cmake \ + git \ + libcurl4-openssl-dev \ + libgmp-dev \ + llvm-11-dev \ + python3-numpy \ + file \ + zlib1g-dev ``` -On Ubuntu 20.04, install gcc-10 which has C++20 support: -```bash -sudo apt-get install -y g++-10 -``` +Configure and build: -To build, make sure you are in the root of the `spring` repo, then run the following command: ```bash mkdir -p build cd build - -## on Ubuntu 20, specify the gcc-10 compiler -cmake -DCMAKE_C_COMPILER=gcc-10 -DCMAKE_CXX_COMPILER=g++-10 -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=/usr/lib/llvm-11 .. - -## on Ubuntu 22, the default gcc version is 11, using the default compiler is fine cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=/usr/lib/llvm-11 .. - make -j "$(nproc)" package ``` -Now you can optionally [test](#step-4---test) your build, or [install](#step-5---install) the `*.deb` binary packages, which will be in the root of your build directory. +For Ubuntu 20.04, install `g++-10` and pass the compiler explicitly: -### Step 4 - Test -Spring supports the following test suites: - -Test Suite | Test Type | [Test Size](https://testing.googleblog.com/2010/12/test-sizes.html) | Notes ----|:---:|:---:|--- -[Parallelizable tests](#parallelizable-tests) | Unit tests | Small -[WASM spec tests](#wasm-spec-tests) | Unit tests | Small | Unit tests for our WASM runtime, each short but _very_ CPU-intensive -[Serial tests](#serial-tests) | Component/Integration | Medium -[Long-running tests](#long-running-tests) | Integration | Medium-to-Large | Tests which take an extraordinarily long amount of time to run +```bash +sudo apt-get install -y g++-10 +cmake -DCMAKE_C_COMPILER=gcc-10 -DCMAKE_CXX_COMPILER=g++-10 \ + -DCMAKE_BUILD_TYPE=Release \ + -DCMAKE_PREFIX_PATH=/usr/lib/llvm-11 .. +``` -When building from source, we recommended running at least the [parallelizable tests](#parallelizable-tests). +## Tests -#### Parallelizable Tests -This test suite consists of any test that does not require shared resources, such as file descriptors, specific folders, or ports, and can therefore be run concurrently in different threads without side effects (hence, easily parallelized). These are mostly unit tests and [small tests](https://testing.googleblog.com/2010/12/test-sizes.html) which complete in a short amount of time. +From the build directory: -You can invoke them by running `ctest` from a terminal in your Spring build directory and specifying the following arguments: ```bash ctest -j "$(nproc)" -LE _tests +ctest -j "$(nproc)" -L wasm_spec_tests +ctest -L "nonparallelizable_tests" ``` -#### WASM Spec Tests -The WASM spec tests verify that our WASM execution engine is compliant with the web assembly standard. These are very [small](https://testing.googleblog.com/2010/12/test-sizes.html), very fast unit tests. However, there are over a thousand of them so the suite can take a little time to run. These tests are extremely CPU-intensive. +Long-running integration tests are available with: -You can invoke them by running `ctest` from a terminal in your Spring build directory and specifying the following arguments: ```bash -ctest -j "$(nproc)" -L wasm_spec_tests +ctest -L "long_running_tests" ``` -We have observed severe performance issues when multiple virtual machines are running this test suite on the same physical host at the same time, for example in a CICD system. This can be resolved by disabling hyperthreading on the host. -#### Serial Tests -The serial test suite consists of [medium](https://testing.googleblog.com/2010/12/test-sizes.html) component or integration tests that use specific paths, ports, rely on process names, or similar, and cannot be run concurrently with other tests. Serial tests can be sensitive to other software running on the same host and they may `SIGKILL` other `nodeos` processes. These tests take a moderate amount of time to complete, but we recommend running them. +## Reproducible Build + +The pinned reproducible Docker build is inherited from Spring and is being +carried forward for TelosZero: -You can invoke them by running `ctest` from a terminal in your Spring build directory and specifying the following arguments: ```bash -ctest -L "nonparallelizable_tests" +DOCKER_BUILDKIT=1 docker build -f tools/reproducible.Dockerfile -o . . ``` -#### Long-Running Tests -The long-running tests are [medium-to-large](https://testing.googleblog.com/2010/12/test-sizes.html) integration tests that rely on shared resources and take a very long time to run. +To reduce memory pressure: -You can invoke them by running `ctest` from a terminal in your Spring build directory and specifying the following arguments: ```bash -ctest -L "long_running_tests" +DOCKER_BUILDKIT=1 docker build \ + --build-arg SPRING_BUILD_JOBS=4 \ + -f tools/reproducible.Dockerfile \ + -o . . ``` -### Step 5 - Install -Once you have [built](#step-3---build-the-source-code) Spring and [tested](#step-4---test) your build, you can install Spring on your system. Don't forget to omit `sudo` if you are running in a docker container. +## Repository Remotes -We recommend installing the binary package you just built. Navigate to your Spring build directory in a terminal and run this command: -```bash -sudo apt-get update -sudo apt-get install -y ./spring_*.deb -``` +Recommended local remotes: -It is also possible to install using `make` instead: -```bash -sudo make install +```text +origin https://github.com/TelosNetwork/teloszero-core.git +upstream https://github.com/AntelopeIO/spring.git +ce https://github.com/eos-amsterdam-rnd/antelope_spring_ce.git ``` -## Bash Autocomplete -`cleos` and `spring-util` offer a substantial amount of functionality. Consider using bash's autocompletion support which makes it easier to discover all their various options. +`origin` is the TelosZero canonical remote. `upstream` is fetch-only for Spring +changes. `ce` is fetch-only for reviewing Spring Community Edition patches. + +## Governance And Security -For our provided `.deb` packages simply install Ubuntu's `bash-completion` package: `apt-get install bash-completion` (you may need to log out/in after installing). +See: -If building from source install the `build/programs/cleos/bash-completion/completions/cleos` and `build/programs/spring-util/bash-completion/completions/spring-util` files to your bash-completion directory. Refer to [bash-completion's documentation](https://github.com/scop/bash-completion#faq) on the possible install locations. +- `GOVERNANCE.md` +- `LEGAL.md` +- `MAINTAINERS.md` +- `PATCHES.md` +- `SECURITY.md` +- `SUPPORT.md` +- `CONTRIBUTING.md` diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000000..536557d6f8 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,25 @@ +# Security Policy + +TelosZero Core is the TelosNetwork-maintained continuation of Antelope Spring. + +## Reporting A Vulnerability + +Report suspected vulnerabilities privately by emailing `devs@telos.net` or by +using GitHub private vulnerability reporting if it is enabled for this +repository. + +Do not open public issues for suspected vulnerabilities. + +## Supported Versions + +Supported versions are the TelosZero release lines explicitly listed in their +release notes and operator guidance. The first public TelosZero release line is +`release/1.2-teloszero`. + +`main` is a development branch and is not a production support channel. + +## Disclosure + +Maintainers should coordinate fixes privately, prepare patched artifacts, and +publish disclosure notes only after affected operators have a safe upgrade +path. diff --git a/SUPPORT.md b/SUPPORT.md new file mode 100644 index 0000000000..c9bf146670 --- /dev/null +++ b/SUPPORT.md @@ -0,0 +1,26 @@ +# Support + +TelosZero Core support is organized around public release branches and tagged +release artifacts. + +## Operator Support + +Operator support begins when a release is explicitly marked operator-ready. +Production release notes should include: + +- supported operating systems +- package names and checksums +- upgrade steps +- rollback steps +- known incompatibilities +- test coverage summary + +## Development Support + +Use GitHub issues or TelosNetwork maintainer channels for: + +- build failures +- packaging issues +- CI runner setup +- release process questions +- upstream patch triage diff --git a/genesis/README.md b/genesis/README.md index aad024ecf4..2976657b11 100644 --- a/genesis/README.md +++ b/genesis/README.md @@ -1,15 +1,19 @@ -## Vaulta Mainnet +## Telos Genesis Files -See also: https://github.com/CryptoLions/EOS-MainNet +This directory contains the public Telos network genesis files used when +starting a node from genesis. -## Jungle testnet +| Network | Genesis file | Chain ID | +| --- | --- | --- | +| Telos Mainnet | `telos_mainnet_genesis.json` | `4667b205c6838ef70ff7988f6e8257e8be0e1284a2f59699054a018f743b1d11` | +| Telos Testnet | `telos_testnet_genesis.json` | `1eaa0824707c8c16bd25145493bf062aecddfeb56c736f6ba6397f3195f33c9f` | -See also: https://github.com/CryptoLions/EOS-Jungle-Testnet +The chain ID files are provided as convenient reference values for +configuration checks and node verification. The canonical chain ID is computed +from the corresponding genesis state. -## Kylin testnet +## Sources -See also: https://github.com/cryptokylin/CryptoKylin-Testnet - -## API Nodes - -- [Greymass API Nodes](https://www.greymass.com/endpoints) +- Telos node template: https://github.com/telosnetwork/node-template +- Telos validator node setup: https://docs.telos.net/nodes/bp-nodes/setting-up-telos-validator-nodes/ +- Telos node operation guide: https://docs.telos.net/nodes/non-bp-nodes/run_a_telos_node/ diff --git a/genesis/jungle_chain_id.json b/genesis/jungle_chain_id.json deleted file mode 100644 index e4c4677508..0000000000 --- a/genesis/jungle_chain_id.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "chain_id": "73e4385a2708e6d7048834fbc1079f2fabb17b3c125b146af438971e90716c4d" -} \ No newline at end of file diff --git a/genesis/jungle_genesis.json b/genesis/jungle_genesis.json deleted file mode 100644 index 574524c7ee..0000000000 --- a/genesis/jungle_genesis.json +++ /dev/null @@ -1,24 +0,0 @@ -{ - "initial_timestamp": "2022-02-22T22:22:22", - "initial_key": "EOS5UAjunGLeR6eBfbpU4CxGssxa9DKKjbPA4zrCuUpoJQwvdpACs", - "initial_configuration": { - "max_block_net_usage": 1048576, - "target_block_net_usage_pct": 1000, - "max_transaction_net_usage": 524287, - "base_per_transaction_net_usage": 12, - "net_usage_leeway": 500, - "context_free_discount_net_usage_num": 20, - "context_free_discount_net_usage_den": 100, - "max_block_cpu_usage": 200000, - "target_block_cpu_usage_pct": 10, - "max_transaction_cpu_usage": 150000, - "min_transaction_cpu_usage": 1, - "max_transaction_lifetime": 3600, - "deferred_trx_expiration_window": 600, - "max_transaction_delay": 3888000, - "max_inline_action_size": 524287, - "max_inline_action_depth": 32, - "max_authority_depth": 6, - "max_ram_size": 68719476736 - } -} \ No newline at end of file diff --git a/genesis/kylin_chain_id.json b/genesis/kylin_chain_id.json deleted file mode 100644 index c559623a7c..0000000000 --- a/genesis/kylin_chain_id.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "chain_id": "5fff1dae8dc8e2fc4d5b23b2c7665c97f9e9d8edf2b6485a86ba311c25639191" -} \ No newline at end of file diff --git a/genesis/telos_mainnet_chain_id.json b/genesis/telos_mainnet_chain_id.json new file mode 100644 index 0000000000..4e8c949080 --- /dev/null +++ b/genesis/telos_mainnet_chain_id.json @@ -0,0 +1,3 @@ +{ + "chain_id": "4667b205c6838ef70ff7988f6e8257e8be0e1284a2f59699054a018f743b1d11" +} diff --git a/genesis/kylin_genesis.json b/genesis/telos_mainnet_genesis.json similarity index 63% rename from genesis/kylin_genesis.json rename to genesis/telos_mainnet_genesis.json index f3c85322a9..39113411ab 100644 --- a/genesis/kylin_genesis.json +++ b/genesis/telos_mainnet_genesis.json @@ -1,23 +1,24 @@ { - "initial_timestamp": "2018-07-11T05:30:00.000", - "initial_key": "EOS7hHHDtnPRbhMmfHJHUEKQyiutKrt9wZPdy1JbaATVLyxpCkrop", + "initial_timestamp": "2018-12-12T10:29:00.000", + "initial_key": "EOS52vfcN43YHHU8Akh7VyfBdnDiMg15dPTELosWG9SR86ssBoU1T", "initial_configuration": { - "max_block_net_usage": 1048576, - "target_block_net_usage_pct": 1000, - "max_transaction_net_usage": 524288, - "base_per_transaction_net_usage": 12, + "max_transaction_delay": 3888000, + "min_transaction_cpu_usage": 100, "net_usage_leeway": 500, - "context_free_discount_net_usage_num": 20, "context_free_discount_net_usage_den": 100, - "max_block_cpu_usage": 200000, - "target_block_cpu_usage_pct": 1000, - "max_transaction_cpu_usage": 150000, - "min_transaction_cpu_usage": 100, + "max_transaction_net_usage": 524288, + "context_free_discount_net_usage_num": 20, "max_transaction_lifetime": 3600, "deferred_trx_expiration_window": 600, - "max_transaction_delay": 3888000, + "max_authority_depth": 6, + "max_transaction_cpu_usage": 5000000, + "max_block_net_usage": 1048576, + "target_block_net_usage_pct": 1000, + "max_generated_transaction_count": 16, "max_inline_action_size": 4096, - "max_inline_action_depth": 4, - "max_authority_depth": 6 + "target_block_cpu_usage_pct": 1000, + "base_per_transaction_net_usage": 12, + "max_block_cpu_usage": 50000000, + "max_inline_action_depth": 4 } -} \ No newline at end of file +} diff --git a/genesis/telos_testnet_chain_id.json b/genesis/telos_testnet_chain_id.json new file mode 100644 index 0000000000..a05086fcea --- /dev/null +++ b/genesis/telos_testnet_chain_id.json @@ -0,0 +1,3 @@ +{ + "chain_id": "1eaa0824707c8c16bd25145493bf062aecddfeb56c736f6ba6397f3195f33c9f" +} diff --git a/genesis/vaulta_genesis.json b/genesis/telos_testnet_genesis.json similarity index 80% rename from genesis/vaulta_genesis.json rename to genesis/telos_testnet_genesis.json index 6520761a25..7499fa44f6 100644 --- a/genesis/vaulta_genesis.json +++ b/genesis/telos_testnet_genesis.json @@ -1,6 +1,6 @@ { - "initial_timestamp": "2018-06-08T08:08:08.888", - "initial_key": "EOS7EarnUhcyYqmdnPon8rm7mBCTnBoot6o7fE2WzjvEX2TdggbL3", + "initial_timestamp": "2019-08-07T12:00:00.000", + "initial_key": "EOS7xyPWfh6743fhZ46zQQcXSctddoqG65d44YsyRnCJCs54mJLrH", "initial_configuration": { "max_block_net_usage": 1048576, "target_block_net_usage_pct": 1000, @@ -9,7 +9,7 @@ "net_usage_leeway": 500, "context_free_discount_net_usage_num": 20, "context_free_discount_net_usage_den": 100, - "max_block_cpu_usage": 200000, + "max_block_cpu_usage": 5000000, "target_block_cpu_usage_pct": 1000, "max_transaction_cpu_usage": 150000, "min_transaction_cpu_usage": 100, diff --git a/genesis/vaulta_chain_id.json b/genesis/vaulta_chain_id.json deleted file mode 100644 index ceb0775ba8..0000000000 --- a/genesis/vaulta_chain_id.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "chain_id": "aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906" -} \ No newline at end of file From bbc2b262ea4ca046041263220d0ce4d614e34850 Mon Sep 17 00:00:00 2001 From: Tobias Date: Thu, 14 May 2026 11:02:20 -0400 Subject: [PATCH 2/3] Make README intro more matter of fact --- README.md | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 61dd82a95c..f0580faa5a 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,12 @@ # TelosZero Core -**The Telos protocol stack has a home again.** +TelosZero Core is the TelosNetwork-maintained continuation of Antelope Spring. +It provides node software and supporting tools for Telos operators, +infrastructure providers, exchanges, tooling teams, and protocol contributors. -TelosZero Core is the TelosNetwork-maintained continuation of Antelope Spring: -a focused, Telos-owned chain software line for operators, infrastructure -providers, exchanges, tooling teams, and protocol contributors who need a -serious production path forward. - -This is not a casual rename. TelosZero keeps the battle-tested Spring runtime -surface, preserves the history that matters, and moves release authority, -packaging, provenance, and long-term maintenance into Telos hands. +TelosZero preserves Spring runtime compatibility while moving release +authority, packaging, provenance, and long-term maintenance under TelosNetwork +stewardship. The runtime command names remain stable: `nodeos`, `cleos`, `keosd`, and `spring-util`. @@ -28,8 +25,8 @@ branches. The first public TelosZero release line is: The initial public release is [`teloszero-v1.2.2`](https://github.com/telosnetwork/teloszero-core/releases/tag/teloszero-v1.2.2). -TelosZero exists to make Telos infrastructure boring in the best possible way: -owned, reviewable, reproducible, and maintained. +The branch and release structure is intended to keep production releases +reviewable, reproducible, and maintained. ## Binary Installation From b29a72df2cbee91921c1d6bc01cfc4593d833a6d Mon Sep 17 00:00:00 2001 From: Tobias Date: Thu, 14 May 2026 11:02:54 -0400 Subject: [PATCH 3/3] Mention quantum-safe roadmap in README --- README.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README.md b/README.md index f0580faa5a..7c11fda9be 100644 --- a/README.md +++ b/README.md @@ -25,6 +25,11 @@ branches. The first public TelosZero release line is: The initial public release is [`teloszero-v1.2.2`](https://github.com/telosnetwork/teloszero-core/releases/tag/teloszero-v1.2.2). +Future development on `main` is where Telos-specific protocol work will be +reviewed, including roadmap work toward quantum-safe Telos infrastructure. +Protocol-level changes must land through explicit design review and release +planning before operator use. + The branch and release structure is intended to keep production releases reviewable, reproducible, and maintained.