diff --git a/CHANGELOG.md b/CHANGELOG.md index c7b2afd..05ce3d0 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -82,7 +82,7 @@ Bugs fixed: * panic on inlined function invocation in compiler (#4002) * list items swap doesn't work as expected in compiler (#4005) * panic on fetching map values with `ok` flag (#3716) - * inability to `go install` neo-go due to `replace` directive in go.mod (#4006) + * inability to `go install` tutus due to `replace` directive in go.mod (#4006) * initialization statement of `switch` is ignored by compiler (#3991) ## 0.112.0 "Hibernation" (29 Aug 2025) @@ -234,7 +234,7 @@ emission (that affects application execution results compatibility with C# node, but likely not critical for anyone). DB resynchronisation for testnet nodes is required (operators of full node may -use `neo-go db reset` command to reset the node's state to height 5894662 and +use `tutus db reset` command to reset the node's state to height 5894662 and avoid full chain resynchronisation). Mainnet DB resynchronisation is not needed. @@ -323,7 +323,7 @@ Bugs fixed: An urgent fix for a very old behavior difference with C# node in Rules witness condition parsing. It suddenly affected testnet compatibility at block 5450030 -and made the chain unprocessable by NeoGo. Please upgrade to fix it, DB is +and made the chain unprocessable by Tutus. Please upgrade to fix it, DB is compatible, no resynchronization required. Bugs fixed: @@ -448,13 +448,13 @@ A large update that introduces a major node extension: NeoFS BlockFetcher servic proposal](https://github.com/neo-project/neo/issues/3463). BlockFetcher service, as an alternative to P2P synchronization mechanism, allows to download blocks and sync chain from block dumps stored in NeoFS. Starting from this release, NeoSPCC team -maintains chain dumps in NeoFS for N3 and NeoFS public networks. The default NeoGo +maintains chain dumps in NeoFS for N3 and NeoFS public networks. The default Tutus node configuration for these networks has been changed to use NeoFS BlockFetcher as a synchronization mechanism prior to P2P synchronization. Other than that, this release includes NEP-24 standard support at both compiler and SC bindings generator levels. A large number of tiny user-facing enhancements is rolled out for RPC actor/ivoker, `neotest` and `unwrap` packages as far as for CLI utilities. Also, -this release contains a set of NeoGo VM bug fixes inspired by differential VM fuzzing +this release contains a set of Tutus VM bug fixes inspired by differential VM fuzzing study conducted by our external contributor @Slava0135 and a set of tiny VM CLI enhancements introduced by @ixje. @@ -510,12 +510,12 @@ Improvements: * explicitly prohibit unknown configuration fields for `contract generate-*` CLI commands (#3708) * extend compiled smart contract identifier in neotest cache (#3709) - * move `neogo_version` metric out of `network` package (#3712) + * move `tutus_version` metric out of `network` package (#3712) Bugs fixed: * fees of ditched transaction are not cleared from mempool (#3537) * extension of SC permission descriptor doesn't clear wildcard status (#3544) - * example of NeoGo VM script fails VM execution (#3593) + * example of Tutus VM script fails VM execution (#3593) * a call to `getunclaimedGas` of native Neo contract for account with zero balance results in VM failure (#3589) * `MODMUL` VM opcode handler returns wrong results for negative arguments (#3599) @@ -576,10 +576,10 @@ Bugs fixed: A 3.7.5-compatible version introducing new Domovoi hardfork that brings two fixes to the protocol: using executing contract state to check contract call permissions -(included into this NeoGo release) and proper VM items refcounting for -System.Runtime.GetNotifications handler (not included into this NeoGo release because +(included into this Tutus release) and proper VM items refcounting for +System.Runtime.GetNotifications handler (not included into this Tutus release because we've never had this bug). Since the second bug is C#-specific and does not lead to -the state differences in mainnet/testnet, we've decided not to break the NeoGo node +the state differences in mainnet/testnet, we've decided not to break the Tutus node to follow pre-Domovoi C# node implementation. Thus, differences in application logs for several T5 transactions before Domovoi hardfork are expected and won't be fixed. @@ -699,7 +699,7 @@ Bugs fixed: #3344, #3340, #3350, #3355, #3364, #3368, #3377, #3393, #3397, #3392, #3398, #3400) * outdated minimum required Go version of boilerplate contract generated by - `neo-go contract init` (#3318) + `tutus contract init` (#3318) * outdated address used as an example in RPC client documentation (#3327) * ungraceful node services shutdown procedure (#3307) * logging data race on node services shutdown (#3307) @@ -735,7 +735,7 @@ Bugs fixed: ## 0.105.0 "Designation" (29 Dec 2023) -We're rolling out an update for NeoGo nodes that contains a number of user-facing +We're rolling out an update for Tutus nodes that contains a number of user-facing API improvements for RPC web-socket notification subsystem, CLI utility, wallet related packages and not only. Try out our new `--await` CLI option for those commands that relay transactions to the network to automatically wait for the @@ -789,7 +789,7 @@ Bugs fixed: ## 0.104.0 "Globalization" (27 Nov 2023) -We're updating NeoGo to push out a number of useful updates and protocol +We're updating Tutus to push out a number of useful updates and protocol extensions as well as make it compatible with 3.6.2 version of C# node. The most invasive behaviour changes are VM-level protocol constraints imposed on the size of serialized stackitems and `NativeActivation` node setting removal. This version @@ -867,11 +867,11 @@ Bugs fixed: ## 0.103.0 "Backwardation" (20 Oct 2023) -A minor 3.6.0-compatible version of NeoGo with new salty ZKP-related +A minor 3.6.0-compatible version of Tutus with new salty ZKP-related functionality, a large batch of deprecated APIs removal and an experimental genesis block extension. Build Groth-16 circuits, generate proofs and deploy verification contracts easily with the new end-to-end ZKP example and `zkpbinding` -NeoGo API. Setup node roles via the node configuration starting from the genesis +Tutus API. Setup node roles via the node configuration starting from the genesis block without any painful multisignature transaction forming and invoke any custom script in the genesis-level transaction with the new `Genesis` protocol configuration extension. And don't forget to move from deprecated RPC client @@ -896,7 +896,7 @@ complete resynchronization on upgrade due to the database storage scheme changes New features: * API for Groth-16 verification contracts autogeneration and end-to-end example for - proving and verifying statements on NeoGo (#3043, #3146) + proving and verifying statements on Tutus (#3043, #3146) * introduce genesis protocol extensions: default node roles designation and genesis transactions (#3168) @@ -936,7 +936,7 @@ Bugs fixed: ## 0.102.0 "Aberration" (06 Sep 2023) -Long-awaited feature-packed 3.6.0-compatible version of NeoGo with all the +Long-awaited feature-packed 3.6.0-compatible version of Tutus with all the appropriate protocol updates and a set of tasty improvements and bug fixes. Groth16 ZKP proof checks are there for contract developers as well as new opcodes. A huge number of improvements went into the RPC server and @@ -990,7 +990,7 @@ Behaviour changes: * hashes and states of native contracts are now accessible via native ContractManagement API (#2991) * `serv_node_version` gauge Prometheus metric is marked as deprecated and - replaced by `neogo_version` and `server_id` (#3009) + replaced by `tutus_version` and `server_id` (#3009) * strict contract script check is back with Basilisk hardfork, it was previously removed in 0.101.3 for 3.5 protocol compatibility (#3056) * JSON number deserialization (via StdLib.jsonDeserialize) changes with @@ -999,7 +999,7 @@ Behaviour changes: * notification type errors are treated as fatal after Basilisk hardfork, before it they're just logged (#3086) * NULL and non-UTF8 items are not allowed for String event types (#3086) - * `Conflicts` and `NotValidBefore` transaction attributes are no longer NeoGo + * `Conflicts` and `NotValidBefore` transaction attributes are no longer Tutus extensions, they can be used on regular networks (#2962) Improvements: @@ -1089,7 +1089,7 @@ the reference C# node implementation way back in neo-project/neo#2266 and added again in neo-project/neo#2849 which is planned to be a part of the upcoming 3.6.0 C# node release. Thus, changes made in the presented 0.101.3 release will be reverted afterwards and strict contract script check will be present in the -next 3.6.0-compatible version of NeoGo node. +next 3.6.0-compatible version of Tutus node. T5 testnet chain requires a complete resynchronization for this version. Mainnet chain resynchronization is recommended. @@ -1182,7 +1182,7 @@ resynchronize. Behaviour changes: * Aspidochelone fork is made to include ContractManagement native contract deploy/update methods call flags change, initially it was an unconditional - part of 0.99.0 NeoGo release (or 3.2.0 C# version), but this behavior is + part of 0.99.0 Tutus release (or 3.2.0 C# version), but this behavior is incompatible with the NeoFS mainnet sidechain; the change to the fork logic does not affect any other public networks (mainnet/testnet) and any new networks that have Aspidochelone enabled since block 0 (#2848) @@ -1194,7 +1194,7 @@ Improvements: ## 0.100.0 "Centuplication" (08 Dec 2022) -A 3.5.0-compatible version of NeoGo with all the appropriate protocol updates +A 3.5.0-compatible version of Tutus with all the appropriate protocol updates and a number of other changes. The most notable ones are configuration updates. New features and some long-standing inconsistencies required for some changes and this release brings them with it. Old configurations are still @@ -1272,7 +1272,7 @@ them, sometimes we ignore them, but they do exist and there are times when they need to be dealt with in one way or another. Most of the bugs fixed in this release have a little less legs than proper insects, they're far from being as critical as the ones fixed in the previous release and yet we -consider them annoying enough to warrant this new version of NeoGo to be +consider them annoying enough to warrant this new version of Tutus to be published. We don't want to see our users fighting these pesky creatures in the wild, better update and have a troublefree experience. @@ -1368,7 +1368,7 @@ related functionality of VM CLI and added an ability to reset chain state to a particular height. An important dBFT initialization bug that caused timestamp-related errors on -block addition was fixed. Also, those who use NeoGo node with +block addition was fixed. Also, those who use Tutus node with EnableCORSWorkaround setting may want to update the node to be able to handle web-socket requests with Origin set in the header. The users of websocket RPC client subscription mechanism are welcomed to move from deprecated subscriptions @@ -1434,7 +1434,7 @@ Bugs fixed: ## 0.99.4 "Transliteration" (07 Oct 2022) A small update mostly interesting for people building/testing smart contracts -with NeoGo. It contains long-awaited VM CLI update that allows to use +with Tutus. It contains long-awaited VM CLI update that allows to use blockchain state and complete set of interops, additional helper functions for smart contracts and notification checking code (for upcoming 3.5.0 protocol changes). Node operators using EnableCORSWorkaround (that is still not @@ -1498,10 +1498,10 @@ New features: * historic smart contract calls can now be made via CLI (#2683) Behavior changes: - * calculatenetworkfee RPC can handle paid attributes (NeoGo extensions) and + * calculatenetworkfee RPC can handle paid attributes (Tutus extensions) and invalid contract signatures now, it won't return an error for them (#2658) * graceful node shutdown on SIGTERM (#2660) - * wallet balance commands now require at least 0.99.1 NeoGo version (or + * wallet balance commands now require at least 0.99.1 Tutus version (or compatible C# node) used by the RPC server (#2667) Improvements: @@ -1543,11 +1543,11 @@ Bugs fixed: ## 0.99.2 "Recalibration" (12 Aug 2022) -This is a 3.4.0-compatible (tested for mainnet and testnet) update to NeoGo +This is a 3.4.0-compatible (tested for mainnet and testnet) update to Tutus that implements all of the required protocol changes, adds a lot of new RPC client interfaces and provides additional service management functions. This is also the first version to support the recently released Go 1.19. Support -for Go 1.16 is removed at the same time, so you need Go 1.17+ to build NeoGo +for Go 1.16 is removed at the same time, so you need Go 1.17+ to build Tutus now. With this version you can turn on/off, restart or reconfigure internal node @@ -1601,7 +1601,7 @@ Improvements: * Go 1.19 support (#2634) * saved transactions created via CLI (`--out`) now use the maximum possible ValidUntilBlock values (#2632) - * RPC server now returns more data about NeoGo-specific protocol extensions + * RPC server now returns more data about Tutus-specific protocol extensions in `getversion` reply (#2632) Bugs fixed: @@ -1614,7 +1614,7 @@ Bugs fixed: ## 0.99.1 "Parametrization" (28 Jul 2022) -We're updating NeoGo to push out a number of significant updates as well as +We're updating Tutus to push out a number of significant updates as well as make it compatible with 3.3.1 version of C# node. The most prominent changes are RPC sessions for iterators returned from invoke* calls, initial bits of RPC client refactoring and support for darwin-arm64 and linux-arm64 @@ -1639,7 +1639,7 @@ New features: use `--wallet-config` option instead of `--wallet` if needed (#2559) * session-based JSON-RPC iterator API for both server and client with `traverseiterator` and `terminatesession` calls; notice that the default - server behavior (`SessionEnabled: false`) is compatible with NeoGo 0.99.0, + server behavior (`SessionEnabled: false`) is compatible with Tutus 0.99.0, iterators are expanded the way they were previously, only when sessions are enabled they're returned by the server to the client (#2555) * `interop` package now provides helper methods for proper `Hash160`, @@ -1684,7 +1684,7 @@ Behavior changes: `result.NotaryRequestEvent` (#2609) Improvements: - * new `make` targets to build NeoGo binaries locally or using Docker + * new `make` targets to build Tutus binaries locally or using Docker environment (#2537, #2541) * more detailed client-side error on JSON-RPC WebSocket connection closure (#2540) @@ -1745,7 +1745,7 @@ Bugs fixed: ## 0.99.0 "Overextrapolation" (03 Jun 2022) -A big NeoGo upgrade that is made to be compatible with C# node version +A big Tutus upgrade that is made to be compatible with C# node version 3.3.0. All of the protocol changes are implemented there with the main one being the Aspidochelone hardfork that will happen on mainnet soon. Compatibility is confirmed for current T5 testnet and mainnet, but this @@ -1974,13 +1974,13 @@ Bugs fixed: ## 0.98.1 "Immunization" (31 Jan 2022) Bug fixes, interesting optimizations, divisible NEP-11 example and a big -compiler update --- everything you wanted to find in this NeoGo update. It +compiler update --- everything you wanted to find in this Tutus update. It requires chain resynchronization, but this resynchronization will be faster than ever. One thing should also be noted, even though this release is 3.1.0-compatible, it is known to have a different state for testnet after block 975644, but it's -not a NeoGo fault, it'll be fixed in the next C# node release. The root cause +not a Tutus fault, it'll be fixed in the next C# node release. The root cause is well-known and is not considered to be critical compatibility-wise. New features: @@ -2102,7 +2102,7 @@ Bugs fixed: ## 0.97.3 "Exception" (13 Oct 2021) -This updated version of NeoGo is made to be compatible with Neo 3.0.3 bringing +This updated version of Tutus is made to be compatible with Neo 3.0.3 bringing with it all corresponding protocol changes and bug fixes so that you can use it on public testnet and mainnet. It also brings with it a complete experimental P2P state exchange extension for private networks as well as @@ -2182,7 +2182,7 @@ Bugs fixed: ## 0.97.2 "Dissipation" (18 Aug 2021) -We're rolling out an update for NeoGo nodes that mostly concentrates on +We're rolling out an update for Tutus nodes that mostly concentrates on performance. We've tweaked and tuned a lot of code while staying compatible with N3 mainnet and testnet. At the same time we're gradually introducing changes required for our P2P state exchange extension and this affected DB @@ -2211,7 +2211,7 @@ Bugs fixed: ## 0.97.1 "Gasification" (06 Aug 2021) -We're updating NeoGo to make it compatible with the latest protocol changes +We're updating Tutus to make it compatible with the latest protocol changes made in 3.0.2 version of C# node. But that's not the only thing we do, this release also fixes one important bug, improves node's performance and adds CLI support to add group signatures to manifests. @@ -2269,7 +2269,7 @@ Bugs fixed: ## 0.96.1 "Brecciation" (23 Jul 2021) New CLI commands, updated dependencies and some bugs fixed --- you can find -all of this in the new NeoGo release. It's compatible with 0.96.0 (except for +all of this in the new Tutus release. It's compatible with 0.96.0 (except for multisignature contexts, but you're not likely to be using them) and confirmed to have proper RC4 testnet state up to 15K blocks (but 0.96.0 is fine wrt this too). At the same time we recommend to resynchronize the chain @@ -2303,14 +2303,14 @@ Bugs fixed: ## 0.96.0 "Aspiration" (21 Jul 2021) -We're updating NeoGo to support RC4 changes, there are some incompatible ones +We're updating Tutus to support RC4 changes, there are some incompatible ones so this version can't be used with RC3 networks/chains (RC3 testnet is still available, please use 0.95.4 for it). This release was checked for RC4 testnet compatibility and has the same state as C# for the first 5K blocks. No significant protocol changes are expected now as we're moving to final N3 release, but we'll keep updating the node fixing bugs (if any), improving -performance and introducing NeoGo-specific features. +performance and introducing Tutus-specific features. New features: * "System.Runtime.GetNetwork" system call (#2043) @@ -2374,7 +2374,7 @@ Now we're releasing 0.95.4 with all of these fixes which is still RC3-compatible and it's stateroot-compatible with C# implementation up to 281K blocks. Please resynchronize to get identic testnet state. And most likely that's the last RC3-compatible release as we're moving forward to the official -3.0.0 release of C# version NeoGo will be updated with appropriate changes +3.0.0 release of C# version Tutus will be updated with appropriate changes (some of which are not compatible with RC3). New features: @@ -2481,7 +2481,7 @@ Bugs fixed: ## 0.95.1 "Shiftiness" (31 May 2021) -Bringing NeoGo up to date with N3 RC3 changes this release also improves +Bringing Tutus up to date with N3 RC3 changes this release also improves compiler and CLI a bit. This release is mostly compatible with 0.95.0, but you need to resynchronize @@ -2600,7 +2600,7 @@ This is the second and much improved N3 RC1-compatible release. We've mostly focused on documentation and examples with this release, so there is a number of updates in this area including oracle contract example and NEP-11 NFT contract example. At the same time proper testnet network revealed some -implementation inconsistencies between NeoGo and C# especially in oracle and +implementation inconsistencies between Tutus and C# especially in oracle and state validation services, so there are fixes for them also. Protocol-wise this release is compatible with 0.94.0, but MPT structures have @@ -2705,7 +2705,7 @@ ready for testnet launch now, so that you could play with new native contracts, VM instructions and other goodies RC1 brings with it. Some usability improvements and documentation updates also went into this release as well as a number of fixes stabilizing Notary subsystem (which is -NeoGo-specific protocol extension). +Tutus-specific protocol extension). Please note that this release is incompatible with 0.93.0. We do plan to make an update soon (with more examples and documentation), but there won't be @@ -2740,7 +2740,7 @@ Behavior changes: require read permission (#1777, #1837) * System.Contract.Call interop function now requires state read permission (#1777) - * NeoGo no longer supports Go 1.13 (#1791) + * Tutus no longer supports Go 1.13 (#1791) * native contract calls are now contract version aware (#1744) * interop wrappers for smart contracts now use `int` type for all integers (#1796) @@ -2778,7 +2778,7 @@ Improvements: * documentation updates (#1778, #1843) * `sendrawtransaction` and `submitblock` RPC calls now return more detailed information about errors for failed submissions (#1773) - * NeoGo now supports Go 1.16 (#1771, #1795) + * Tutus now supports Go 1.16 (#1771, #1795) * NEP-17 transfer tracking was optimized to avoid some DB accesses (#1782) * interop wrappers added for SIGN/ABS/MAX/MIN/WITHIN instructions (#1796) @@ -2811,16 +2811,16 @@ Bugs fixed: This is a 3.0.0-preview5 compatible release with important protocol changes, improved smart contract interop interface for native contracts (it's much -easier now to use them) and complete Notary subsystem which is a NeoGo +easier now to use them) and complete Notary subsystem which is a Tutus experimental protocol extension for P2P signature collection. Please note that this release is incompatible with 0.92.0 and there are no plans for long-term support of it, Neo 3 is still changing and improving. The release is tested with preview5 testnet data (and one of testnet CNs is -already a neo-go node) up to 48K blocks and it has exactly the same storage +already a tutus node) up to 48K blocks and it has exactly the same storage data except for the Ledger contract that technically can differ between nodes -(it's not a part of state proper), and in case of neo-go it's intentionally +(it's not a part of state proper), and in case of tutus it's intentionally different (but this doesn't affect contract's functionality and state roots compatibility). @@ -2911,10 +2911,10 @@ Bugs fixed: ## 0.92.0 "Fermentation" (28 Dec 2020) -NeoGo project is closing year 2020 with 3.0.0-preview4 compatible release that +Tutus project is closing year 2020 with 3.0.0-preview4 compatible release that also has much improved performance, a lot of updates to compiler and SDK and some experimental protocol extensions. This release also is the most tested -release of NeoGo ever, we've reached 83% code coverage (Neo 2.x only has +release of Tutus ever, we've reached 83% code coverage (Neo 2.x only has 66%). Please note that this release is incompatible with 0.91.0 and there are no @@ -2922,7 +2922,7 @@ plans for long-term support of it, Neo 3 is still changing and improving. Protocol-wise this release is tested with preview4 testnet (including working in consensus with C# nodes) and it is compatible with it even though there are -some known storage change mismatches between NeoGo and C# (functionally the +some known storage change mismatches between Tutus and C# (functionally the contents is the same, this mismatch is caused by JSON handling differences and needs to be addressed at the protocol level). @@ -3143,8 +3143,8 @@ Bugs fixed: ## 0.91.0 "Ululation" (18 August 2020) -We've updated NeoGo for 3.0.0-preview3 compatibility implementing all the -appropriate protocol changes as well as improving NeoGo-specific +We've updated Tutus for 3.0.0-preview3 compatibility implementing all the +appropriate protocol changes as well as improving Tutus-specific components. This release brings with it significant changes for smart contracts, both in terms of Neo protocol changes (no more there is a single entry point! execution environment has also changed in lots of ways) and Go @@ -3159,7 +3159,7 @@ that also changed hashes and addresses. But nonetheless it is tested to be compatible with preview3 testnet for up to 68K of blocks in terms of storage changes, with neo-debugger for debug data produced by the compiler and with consensus process for heterogeneous setups -(like 2 neo-go CNs with 2 C# CNs). +(like 2 tutus CNs with 2 C# CNs). New features: * secp256k1 signature checks added to interop functions @@ -3233,7 +3233,7 @@ Behavior changes: * governance scheme was changed to delegated committee-based one. The number of validators is now specified with ValidatorsCount configuration option, standby validators are no longer being registered by default (#867, #1300) - * Go 1.13+ is now required to build neo-go (#1281) + * Go 1.13+ is now required to build tutus (#1281) * public contract methods now always return some value and this is being checked by the VM (#1196, #1331, #1332) * runtime interop package now exports triggers as proper constants rather @@ -3306,7 +3306,7 @@ Bugs fixed: ## 0.90.0 "Tantalization" (14 July 2020) -The first Neo 3 compatible release of neo-go! We've targeted to make it +The first Neo 3 compatible release of tutus! We've targeted to make it compatible with preview2 release of Neo 3, so it only contains features available there, but at the same time this makes the node more useful until we have some more up to date reference version. It's a completely different @@ -3335,14 +3335,14 @@ Things that have also changed: * notification subsystem * executable format output for compiler -Compatibility level of this neo-go release: +Compatibility level of this tutus release: * identical storage changes compared to C# node for 378K blocks of preview2 testnet * debugging info produced is compatible with preview2-compatible neo-debugger - * running consensus nodes in heterogeneous setup is possible (2 neo-go CNs + * running consensus nodes in heterogeneous setup is possible (2 tutus CNs with 2 C# CNs, for example) -Changes specific to neo-go: +Changes specific to tutus: * some CLI parameters like wallet path or RPC endpoint URL have been unified across all commands and thus have changed in some of them (refer to CLI help for details) @@ -3352,7 +3352,7 @@ Changes specific to neo-go: * we no longer provide bootstrapping 6k block dump for private networks, you have 30000000 GAS right in the genesis block and it's not hard to make use of it (see - [neo-go-sc-wrkshp](https://github.com/tutus-one/tutus-chain-sc-wrkshp) for an + [tutus-sc-wrkshp](https://github.com/tutus-one/tutus-chain-sc-wrkshp) for an example of how to use it) * we have a conversion tool for your old Neo 2 wallets (`wallet convert` command), so you can reuse keys on Neo 3 networks diff --git a/README.md b/README.md index 2e390d8..91ed019 100644 --- a/README.md +++ b/README.md @@ -1,88 +1,192 @@ -# Tutus Chain +

+

Tutus

+

+ Sovereign Blockchain Infrastructure for Government +

+

+ Website | + Quick Start | + Documentation | + License +

+

-Sovereign blockchain platform for government deployments. Forked from [NeoGo](https://github.com/nspcc-dev/neo-go). - -**Website:** tutus.one -**License:** Apache 2.0 +--- ## Overview -Tutus is an independent blockchain designed for government-grade deployments with: +Tutus is a high-performance blockchain platform engineered for sovereign government deployments. It provides the foundational infrastructure for digital identity, democratic governance, universal services, and transparent economics at national scale. -- **Sovereign instances** - Each government runs their own chain -- **1-second blocks** - Fast finality with dBFT consensus -- **7 validators** - Government-controlled consensus nodes -- **Zero gas for citizens** - Native contracts subsidize operations -- **Inter-government bridge** - Optional cross-border interoperability +### Key Features -## Building +- **Sovereign Architecture** — Each government operates an independent blockchain instance with full data sovereignty +- **Sub-Second Finality** — 1-second block times with deterministic Byzantine Fault Tolerant (dBFT) consensus +- **Zero-Cost Citizen Access** — Native fee subsidization ensures universal access regardless of economic status +- **Constitutional Rights Framework** — 14 immutable rights encoded directly into the protocol +- **Cross-Border Interoperability** — Optional federation protocol for inter-government cooperation -Requires Go 1.24+ and `make`: +### Performance -```bash -make build -``` +| Metric | Value | +|--------|-------| +| Block Time | 1 second | +| Finality | Immediate (dBFT) | +| Throughput | ~30,000 TPS | +| Validators | Configurable (default: 7) | -The resulting binary is `bin/tutus`. +## Native Contracts -## Running a Node - -Start a Tutus node: - -```bash -./bin/tutus node --config-file ./config/protocol.tutus.yml -``` - -For testnet: - -```bash -./bin/tutus node --config-file ./config/protocol.tutus.testnet.yml -``` - -## Network Flags - -- `--tutus` - Tutus mainnet (government deployment) -- `--tutus-testnet` - Tutus testnet - -## Configuration - -Network configurations are in `./config/`: - -| File | Purpose | -|------|---------| -| `protocol.tutus.yml` | Production government deployment | -| `protocol.tutus.testnet.yml` | Development testnet | - -## Docker - -```bash -docker build -t tutus-chain . -docker run -d --name tutus -p 10333:10333 -p 10332:10332 tutus-chain -``` - -## Native Contracts (Planned) - -The following will be built into the Tutus protocol: +Tutus includes purpose-built native contracts for government operations: | Contract | Purpose | |----------|---------| -| PersonToken | Soul-bound identity | -| Scire | Universal education | -| Salus | Universal healthcare | -| Sese | Life planning | -| Tribute | Anti-hoarding economics | -| VTS | Government stablecoin | -| Eligere | Democratic voting | +| **Vita** | Soul-bound identity token (one per person) | +| **Annos** | Lifespan and age verification | +| **Lex** | Constitutional rights and legal framework | +| **Scire** | Universal education infrastructure | +| **Salus** | Universal healthcare management | +| **Sese** | Life planning and sabbaticals | +| **Eligere** | Democratic voting and governance | +| **VTS** | Government-backed stablecoin | +| **Tribute** | Anti-hoarding economic policy | +| **Collocatio** | Citizen investment opportunities | +| **Federation** | Cross-chain identity coordination | +| **Pons** | Inter-government bridge protocol | +| **Palam** | Transparency and audit ledger | -## Validator Setup +## Quick Start -See [docs/validator.md](docs/validator.md) for government validator deployment. +### Prerequisites -## Origin +- Go 1.24 or higher +- Make -Tutus is forked from NeoGo, the Go implementation of the Neo N3 blockchain. -We maintain compatibility with the Neo VM while extending the protocol for government use cases. +### Building + +```bash +git clone https://github.com/tutus-one/tutus-chain.git +cd tutus-chain +make build +``` + +The compiled binary is located at `bin/tutus`. + +### Running a Node + +```bash +# Development +./bin/tutus node --config-file ./config/protocol.tutus.testnet.yml + +# Production +./bin/tutus node --config-file ./config/protocol.tutus.yml +``` + +### Docker Deployment + +```bash +# Build image +docker build -t tutus . + +# Run node +docker run -d \ + --name tutus-node \ + -p 10333:10333 \ + -p 10332:10332 \ + -v tutus-data:/chains \ + tutus + +# Multi-node testnet +docker-compose up -d +``` + +## Documentation + +| Document | Description | +|----------|-------------| +| [Node Configuration](docs/node-configuration.md) | Full configuration reference | +| [Consensus](docs/consensus.md) | dBFT consensus protocol | +| [RPC API](docs/rpc.md) | JSON-RPC interface | +| [CLI Reference](docs/cli.md) | Command-line interface | +| [Smart Contracts](docs/compiler.md) | Contract development | +| [Oracle](docs/oracle.md) | External data integration | +| [Notary](docs/notary.md) | Multi-signature transactions | + +## Architecture + +``` +┌─────────────────────────────────────────────────────────────┐ +│ Government Instance │ +├─────────────────────────────────────────────────────────────┤ +│ Citizens │ Services │ Governance │ Economics │ +│ ───────── │ ───────── │ ─────────── │ ────────── │ +│ Vita │ Scire │ Eligere │ VTS │ +│ Annos │ Salus │ Lex │ Tribute │ +│ │ Sese │ │ Collocatio │ +├─────────────────────────────────────────────────────────────┤ +│ Federation Layer (Optional) │ +│ ───────────────────────────────────────────────────────── │ +│ Federation (Cross-chain Vita) │ Pons (Inter-gov Bridge) │ +└─────────────────────────────────────────────────────────────┘ +``` + +## Configuration + +Network configurations are located in `./config/`: + +| Configuration | Purpose | +|---------------|---------| +| `protocol.tutus.yml` | Production deployment | +| `protocol.tutus.testnet.yml` | Public testnet | +| `protocol.tutus.alpha.*.yml` | Alpha testnet instance | +| `protocol.tutus.beta.*.yml` | Beta testnet instance | + +## Security + +Tutus implements comprehensive security measures: + +- **Domain-Specific Committees** — Separate authority for legal, health, education, economic, identity, and governance operations +- **Circuit Breakers** — Automatic operation halting on anomaly detection +- **Formal Invariants** — Runtime verification of critical protocol properties +- **Comprehensive Audit Logging** — Full traceability of all operations + +For security issues, contact: security@tutus.one + +## Contributing + +We welcome contributions from the community. Please read our [Contributing Guidelines](CONTRIBUTING.md) before submitting pull requests. + +## About + +Tutus is developed by **MarketAlly** as critical infrastructure for the future of digital governance. + +**Lead Architect:** David H. Friedel Jr. + +### Acknowledgments + +Tutus is built upon the foundation of the [Neo](https://neo.org) blockchain's Go implementation. We gratefully acknowledge the Neo community's contributions to blockchain technology. ## License -Apache 2.0 - See [LICENSE.md](LICENSE.md) +Tutus is licensed under the [Apache License 2.0](LICENSE.md). + +``` +Copyright 2024-2025 MarketAlly + +Licensed under the Apache License, Version 2.0 (the "License"); +you may not use this file except in compliance with the License. +You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an "AS IS" BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. +``` + +--- + +

+ Built with purpose for humanity's digital future +

diff --git a/ROADMAP.md b/ROADMAP.md index 39e36a7..25a87c3 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,6 +1,6 @@ -# Roadmap for neo-go +# Roadmap for tutus -This defines approximate plan of neo-go releases and key features planned for +This defines approximate plan of tutus releases and key features planned for them. Things can change if there is a need to push a bugfix or some critical functionality. diff --git a/docs/cli.md b/docs/cli.md index bbd374e..eebfab2 100644 --- a/docs/cli.md +++ b/docs/cli.md @@ -1,22 +1,22 @@ -# NeoGo CLI interface +# Tutus CLI interface -NeoGo CLI provides all functionality from one binary. It's used to run +Tutus CLI provides all functionality from one binary. It's used to run a node, create/compile/deploy/invoke/debug smart contracts, run vm and operate with a wallet. Standard setup assumes that you run a node as a separate process, and it doesn't provide any CLI of its own. Instead, it just -makes RPC interface available for you. To perform any actions, you invoke NeoGo +makes RPC interface available for you. To perform any actions, you invoke Tutus as a client that connects to this RPC node and does things you want it to do (like transferring some NEP-17 asset). All CLI commands have corresponding help messages, use `--help` option to get them, for example: ``` -./bin/neo-go db --help +./bin/tutus db --help ``` ## Running node -Use `node` command to run a NeoGo node, it will be configured using a YAML +Use `node` command to run a Tutus node, it will be configured using a YAML file that contains network parameters as well as node settings. ### Configuration @@ -31,13 +31,13 @@ All config files are located in `./config` and they are differentiated according If you want to use some non-default configuration directory path, specify `--config-path` flag: -`./bin/neo-go node --config-path /user/yourConfigPath` +`./bin/tutus node --config-path /user/yourConfigPath` The file loaded is chosen automatically depending on network mode flag. Or just provide path to the configuration file using `--config-file` flag: -`./bin/neo-go node --config-file /user/yourConfigPath/yourConfigFile.yml` +`./bin/tutus node --config-file /user/yourConfigPath/yourConfigFile.yml` Refer to the [node configuration documentation](./node-configuration.md) for detailed configuration file description. @@ -47,13 +47,13 @@ detailed configuration file description. To start Neo node on private network, use: ``` -./bin/neo-go node +./bin/tutus node ``` Or specify a different network with an appropriate flag like this: ``` -./bin/neo-go node --mainnet +./bin/tutus node --mainnet ``` By default, the node will run in the foreground using current standard output for @@ -98,12 +98,12 @@ Typical scenarios when this can be useful (without full node restart): ### DB import/exports/reset -Node operates using some database as a backend to store blockchain data. NeoGo +Node operates using some database as a backend to store blockchain data. Tutus allows to dump chain into a file from the database (when node is stopped) or to import blocks from a file into the database (also when node is stopped). Use `db` command for that. -NeoGo allows to reset the node state to a particular point. It is possible for +Tutus allows to reset the node state to a particular point. It is possible for those nodes that do store complete chain state or for nodes with `RemoveUntraceableBlocks` setting on that are not yet reached `MaxTraceableBlocks` number of blocks. Use `db reset` command with the target block specified to roll back all the changes @@ -146,7 +146,7 @@ path can be used to read the wallet from the standard input. Use `wallet init` command to create a new wallet: ``` -./bin/neo-go wallet init -w wallet.nep6 +./bin/tutus wallet init -w wallet.nep6 { "version": "1.0", @@ -167,7 +167,7 @@ wallet successfully created, file location is wallet.nep6 where "wallet.nep6" is a wallet file name. This wallet will be empty. To generate a new key pair and add an account for it, use `-a` option: ``` -./bin/neo-go wallet init -w wallet.nep6 -a +./bin/tutus wallet init -w wallet.nep6 -a Enter the name of the account > Name Enter passphrase > Confirm passphrase > @@ -208,7 +208,7 @@ wallet successfully created, file location is wallet.nep6 or use `wallet create` command to create a new account in an existing wallet: ``` -./bin/neo-go wallet create -w wallet.nep6 +./bin/tutus wallet create -w wallet.nep6 Enter the name of the account > Joe Random Enter passphrase > Confirm passphrase > @@ -221,7 +221,7 @@ Legacy. New wallet is specified in `-o` option, it will have the same keys with Neo N3 addresses (notice that it doesn't do anything to your assets, it just allows to reuse the old key on N3 network). ``` -./bin/neo-go wallet convert -w old.nep6 -o new.nep6 +./bin/tutus wallet convert -w old.nep6 -o new.nep6 ``` #### Check wallet contents @@ -229,7 +229,7 @@ just allows to reuse the old key on N3 network). its output is the same NEP-6 JSON, but better formatted. You can also decrypt keys at the same time with `-d` option (you'll be prompted for password): ``` -./bin/neo-go wallet dump -w wallet.nep6 -d +./bin/tutus wallet dump -w wallet.nep6 -d Enter wallet password > { @@ -267,7 +267,7 @@ Enter wallet password > You can also get public keys for addresses stored in your wallet with `wallet dump-keys` command: ``` -./bin/neo-go wallet dump-keys -w wallet.nep6 +./bin/tutus wallet dump-keys -w wallet.nep6 NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E (simple signature contract): 03cecd63d7d8120c3b194c3b2880dd4aafe1475c57e40c852872d7305615258140 ``` @@ -276,7 +276,7 @@ NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E (simple signature contract): `wallet export` allows you to export a private key in NEP-2 encrypted or WIF (unencrypted) form (`-d` flag). ``` -$ ./bin/neo-go wallet export -w wallet.nep6 -d NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E +$ ./bin/tutus wallet export -w wallet.nep6 -d NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E Enter password > KyswN8r48dhsvyQJVy97RWnZmKgYLrXv9mCL81Kb4vAagZiCsePv ``` @@ -285,7 +285,7 @@ KyswN8r48dhsvyQJVy97RWnZmKgYLrXv9mCL81Kb4vAagZiCsePv You can import NEP-2 or WIF private key along with verification contract (if it's non-standard): ``` -./bin/neo-go wallet import --wif KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7 -w wallet.nep6 +./bin/tutus wallet import --wif KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7 -w wallet.nep6 Provided WIF was unencrypted. Wallet can contain only encrypted keys. Enter the name of the account > New Account Enter passphrase > @@ -310,17 +310,17 @@ offline signing). Use with care, don't lose your keys with it. `wallet candidate` provides commands to register or unregister a committee (and therefore validator) candidate key: ``` -./bin/neo-go wallet candidate register -a NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E -w wallet.json -r http://localhost:20332 +./bin/tutus wallet candidate register -a NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E -w wallet.json -r http://localhost:20332 ``` You can also vote for candidates if you own NEO: ``` -./bin/neo-go wallet candidate vote -a NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E -w wallet.json -r http://localhost:20332 -c 03cecd63d7d8120c3b194c3b2880dd4aafe1475c57e40c852872d7305615258140 +./bin/tutus wallet candidate vote -a NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E -w wallet.json -r http://localhost:20332 -c 03cecd63d7d8120c3b194c3b2880dd4aafe1475c57e40c852872d7305615258140 ``` Do not provide candidate argument to perform unvoting: ``` -./bin/neo-go wallet candidate vote -a NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E -w wallet.json -r http://localhost:20332 +./bin/tutus wallet candidate vote -a NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E -w wallet.json -r http://localhost:20332 ``` ### Getting data from chain @@ -328,7 +328,7 @@ Do not provide candidate argument to perform unvoting: #### Node height/validated height `query height` returns the latest block and validated state height: ``` -$ ./bin/neo-go query height -r http://localhost:20332 +$ ./bin/tutus query height -r http://localhost:20332 Latest block: 11926 Validated state: 11926 ``` @@ -336,7 +336,7 @@ Validated state: 11926 #### Transaction status `query tx` provides convenient wrapper over RPC calls to query transaction status. ``` -./bin/neo-go query tx --rpc-endpoint http://localhost:20332 aaf87628851e0c03ee086ff88596bc24de87082e9e5c73d75bb1c740d1d68088 +./bin/tutus query tx --rpc-endpoint http://localhost:20332 aaf87628851e0c03ee086ff88596bc24de87082e9e5c73d75bb1c740d1d68088 Hash: aaf87628851e0c03ee086ff88596bc24de87082e9e5c73d75bb1c740d1d68088 OnChain: true BlockHash: fabcd46e93b8f4e1bc5689e3e0cc59704320494f7a0265b91ae78b4d747ee93b @@ -348,7 +348,7 @@ if it has been executed successfully. #### Committee members `query committee` returns a list of current committee members: ``` -$ ./bin/neo-go query committee -r http://localhost:20332 +$ ./bin/tutus query committee -r http://localhost:20332 03009b7540e10f2562e5fd8fac9eaec25166a58b26e412348ff5a86927bfac22a2 030205e9cefaea5a1dfc580af20c8d5aa2468bb0148f1a5e4605fc622c80e604ba 0207da870cedb777fceff948641021714ec815110ca111ccc7a54c168e065bda70 @@ -376,7 +376,7 @@ $ ./bin/neo-go query committee -r http://localhost:20332 `query candidates` returns all current candidates, number of votes for them and their committee/consensus status: ``` -$ ./bin/neo-go query candidates -r http://localhost:20332 +$ ./bin/tutus query candidates -r http://localhost:20332 Key Votes Committee Consensus 03009b7540e10f2562e5fd8fac9eaec25166a58b26e412348ff5a86927bfac22a2 2000000 true true 030205e9cefaea5a1dfc580af20c8d5aa2468bb0148f1a5e4605fc622c80e604ba 2000000 true true @@ -405,7 +405,7 @@ Key Votes Com the candidate it voted for (if any) and the block number of the last transactions involving NEO on this account: ``` -$ ./bin/neo-go query voter -r http://localhost:20332 Nj91C8TxQSxW1jCE1ytFre6mg5qxTypg1Y +$ ./bin/tutus query voter -r http://localhost:20332 Nj91C8TxQSxW1jCE1ytFre6mg5qxTypg1Y Voted: 0214baf0ceea3a66f17e7e1e839ea25fd8bed6cd82e6bb6e68250189065f44ff01 (Nj91C8TxQSxW1jCE1ytFre6mg5qxTypg1Y) Amount : 2000000 Block: 3970 @@ -426,13 +426,13 @@ For example, you have a four-node default network setup and want to set some key for the oracle role, you create transaction with: ``` -$ neo-go contract invokefunction -w .docker/wallets/wallet1.json --out some.part.json -a NVTiAjNgagDkTr5HTzDmQP9kPwPHN5BgVq -r http://localhost:30333 0x49cf4e5378ffcd4dec034fd98a174c5491e395e2 designateAsRole 8 \[ 02b3622bf4017bdfe317c58aed5f4c753f206b7db896046fa7d774bbc4bf7f8dc2 \] -- NVTiAjNgagDkTr5HTzDmQP9kPwPHN5BgVq:CalledByEntry +$ tutus contract invokefunction -w .docker/wallets/wallet1.json --out some.part.json -a NVTiAjNgagDkTr5HTzDmQP9kPwPHN5BgVq -r http://localhost:30333 0x49cf4e5378ffcd4dec034fd98a174c5491e395e2 designateAsRole 8 \[ 02b3622bf4017bdfe317c58aed5f4c753f206b7db896046fa7d774bbc4bf7f8dc2 \] -- NVTiAjNgagDkTr5HTzDmQP9kPwPHN5BgVq:CalledByEntry ``` And then sign it with two more keys: ``` -$ neo-go wallet sign -w .docker/wallets/wallet2.json --in some.part.json --out some.part.json -a NVTiAjNgagDkTr5HTzDmQP9kPwPHN5BgVq -$ neo-go wallet sign -w .docker/wallets/wallet3.json --in some.part.json -r http://localhost:30333 -a NVTiAjNgagDkTr5HTzDmQP9kPwPHN5BgVq +$ tutus wallet sign -w .docker/wallets/wallet2.json --in some.part.json --out some.part.json -a NVTiAjNgagDkTr5HTzDmQP9kPwPHN5BgVq +$ tutus wallet sign -w .docker/wallets/wallet3.json --in some.part.json -r http://localhost:30333 -a NVTiAjNgagDkTr5HTzDmQP9kPwPHN5BgVq ``` Notice that the last command sends the transaction (which has a complete set of signatures for 3/4 multisignature account by that time) to the network. @@ -445,7 +445,7 @@ machine: ``` $ cp wallet.json wallet.stripped.json # don't lose the original wallet -$ neo-go wallet strip-keys --wallet wallet.stripped.json +$ tutus wallet strip-keys --wallet wallet.stripped.json ``` This wallet has no keys inside (but has appropriate scripts/addresses), so it @@ -453,7 +453,7 @@ can be safely shared with anyone or transferred to network-enabled machine where you then can create a transfer transaction: ``` -$ neo-go wallet nep17 transfer --rpc-endpoint http://localhost:20332 \ +$ tutus wallet nep17 transfer --rpc-endpoint http://localhost:20332 \ --wallet wallet.stripped.json --from NjEQfanGEXihz85eTnacQuhqhNnA6LxpLp \ --to Nj91C8TxQSxW1jCE1ytFre6mg5qxTypg1Y --token NEO --amount 1 --out context.json @@ -461,7 +461,7 @@ $ neo-go wallet nep17 transfer --rpc-endpoint http://localhost:20332 \ `context.json` can now be transferred to the machine with the `wallet.json` containing proper keys and signed: ``` -$ neo-go wallet sign --wallet wallet.json \ +$ tutus wallet sign --wallet wallet.json \ -address NjEQfanGEXihz85eTnacQuhqhNnA6LxpLp --in context.json --out context.json ``` Now `context.json` contains a transaction with a complete set of signatures @@ -469,7 +469,7 @@ Now `context.json` contains a transaction with a complete set of signatures well). It can be transferred to network-enabled machine again and the transaction can be sent to the network: ``` -$ neo-go util sendtx --rpc-endpoint http://localhost:20332 context.json +$ tutus util sendtx --rpc-endpoint http://localhost:20332 context.json ``` ### NEP-17 token functions @@ -478,15 +478,15 @@ $ neo-go util sendtx --rpc-endpoint http://localhost:20332 context.json #### Token metadata -NEP-17 commands are designed to work with any NEP-17 tokens, but NeoGo needs +NEP-17 commands are designed to work with any NEP-17 tokens, but Tutus needs some metadata for these tokens to function properly. Native NEO or GAS are -known to NeoGo by default, but other tokens are not. NeoGo can get this +known to Tutus by default, but other tokens are not. Tutus can get this metadata from the specified RPC server, but that's an additional request to make. So, if you care about command processing delay, you can import token metadata into the wallet with `wallet nep17 import` command. It'll be stored in the `extra` section of the wallet. ``` -./bin/neo-go wallet nep17 import -w wallet.nep6 -r http://localhost:20332 -t abcdefc189f30098b0ba6a2eb90b3a925800ffff +./bin/tutus wallet nep17 import -w wallet.nep6 -r http://localhost:20332 -t abcdefc189f30098b0ba6a2eb90b3a925800ffff ``` You can later see what token data you have in your wallet with `wallet nep17 @@ -495,7 +495,7 @@ info` command and remove tokens you don't need with `wallet nep17 remove`. #### Balance Getting balance is easy: ``` -./bin/neo-go wallet nep17 balance -w /etc/neo-go/wallet.json -r http://localhost:20332 +./bin/tutus wallet nep17 balance -w /etc/tutus/wallet.json -r http://localhost:20332 ``` By default, you'll get data for all tokens that are owned by all accounts @@ -510,7 +510,7 @@ the RPC server (or saves to file if it needs to be signed by multiple parties). For example, transferring 100 GAS looks like this: ``` -./bin/neo-go wallet nep17 transfer -w wallet.nep6 -r http://localhost:20332 --to NjEQfanGEXihz85eTnacQuhqhNnA6LxpLp --from NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E --token GAS --amount 100 +./bin/tutus wallet nep17 transfer -w wallet.nep6 -r http://localhost:20332 --to NjEQfanGEXihz85eTnacQuhqhNnA6LxpLp --from NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E --token GAS --amount 100 ``` You can omit `--from` parameter (default wallet's address will be used in this @@ -530,7 +530,7 @@ you don't have `--token`, `--to` and `--amount` options, but instead you can specify multiple "token:addr:amount" sets after all other options. The same transfer as above can be done with `multitransfer` by doing this: ``` -./bin/neo-go wallet nep17 multitransfer -w wallet.nep6 -r http://localhost:20332 --from NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E GAS:NjEQfanGEXihz85eTnacQuhqhNnA6LxpLp:100 +./bin/tutus wallet nep17 multitransfer -w wallet.nep6 -r http://localhost:20332 --from NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E GAS:NjEQfanGEXihz85eTnacQuhqhNnA6LxpLp:100 ``` #### GAS claims @@ -554,7 +554,7 @@ commands with the following adjustments. Specify token ID via `--id` flag to get data for a particular NFT: ``` -./bin/neo-go wallet nep11 balance -w /etc/neo-go/wallet.json --token 67ecb7766dba4acf7c877392207984d1b4d15731 --id 7e244ffd6aa85fb1579d2ed22e9b761ab62e3486 -r http://localhost:20332 +./bin/tutus wallet nep11 balance -w /etc/tutus/wallet.json --token 67ecb7766dba4acf7c877392207984d1b4d15731 --id 7e244ffd6aa85fb1579d2ed22e9b761ab62e3486 -r http://localhost:20332 ``` By default, no token ID specified, i.e all NFTs returned by the server are listed. @@ -565,7 +565,7 @@ Specify token ID via `--id` flag to transfer NEP-11 token. Specify the amount to transfer divisible NEP-11 token: ``` -./bin/neo-go wallet nep11 transfer -w wallet.nep6 -r http://localhost:20332 --to NjEQfanGEXihz85eTnacQuhqhNnA6LxpLp --from NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E --token 67ecb7766dba4acf7c877392207984d1b4d15731 --id R5OREI5BU+Uyd23/MuV/xzI3F+Q= --amount 5 +./bin/tutus wallet nep11 transfer -w wallet.nep6 -r http://localhost:20332 --to NjEQfanGEXihz85eTnacQuhqhNnA6LxpLp --from NMe64G6j6nkPZby26JAgpaCNrn1Ee4wW6E --token 67ecb7766dba4acf7c877392207984d1b4d15731 --id R5OREI5BU+Uyd23/MuV/xzI3F+Q= --amount 5 ``` By default, no amount is specified, i.e. the whole token is transferred for @@ -581,7 +581,7 @@ To print token IDs owned by the specified owner, use `tokensOf` command with `--token` and `--address` flags: ``` -./bin/neo-go wallet nep11 tokensOf -r http://localhost:20332 --token 67ecb7766dba4acf7c877392207984d1b4d15731 --address NbrUYaZgyhSkNoRo9ugRyEMdUZxrhkNaWB +./bin/tutus wallet nep11 tokensOf -r http://localhost:20332 --token 67ecb7766dba4acf7c877392207984d1b4d15731 --address NbrUYaZgyhSkNoRo9ugRyEMdUZxrhkNaWB ``` #### Owner Of @@ -591,7 +591,7 @@ use `ownerOf` method, specify token hash via `--token` flag and token ID via `--id` flag: ``` -./bin/neo-go wallet nep11 ownerOf -r http://localhost:20332 --token 67ecb7766dba4acf7c877392207984d1b4d15731 --id R5OREI5BU+Uyd23/MuV/xzI3F+Q= +./bin/tutus wallet nep11 ownerOf -r http://localhost:20332 --token 67ecb7766dba4acf7c877392207984d1b4d15731 --id R5OREI5BU+Uyd23/MuV/xzI3F+Q= ``` #### Optional methods @@ -602,7 +602,7 @@ If NEP-11 token supports optional `properties` method, specify token hash via `--token` flag and token ID via `--id` flag to print properties: ``` -./bin/neo-go wallet nep11 properties -r http://localhost:20332 --token 67ecb7766dba4acf7c877392207984d1b4d15731 --id 7V5gjT2WwjP3pBCQMKGMfyZsp/w= +./bin/tutus wallet nep11 properties -r http://localhost:20332 --token 67ecb7766dba4acf7c877392207984d1b4d15731 --id 7V5gjT2WwjP3pBCQMKGMfyZsp/w= ``` ##### 2. Tokens @@ -611,19 +611,19 @@ If NEP-11 token supports optional `tokens` method, specify token hash via `--token` flag to print the list of token IDs minted by the specified NFT: ``` -./bin/neo-go wallet nep11 tokens -r http://localhost:20332 --token 67ecb7766dba4acf7c877392207984d1b4d15731 +./bin/tutus wallet nep11 tokens -r http://localhost:20332 --token 67ecb7766dba4acf7c877392207984d1b4d15731 ``` ## Utility commands ### Value conversion -NeoGo provides conversion utility command to reverse data, convert script +Tutus provides conversion utility command to reverse data, convert script hashes to/from address, convert public keys to hashes/addresses, convert data to/from hexadecimal or base64 representation. All of this is done by a single `util convert` command like this: ``` -$ ./bin/neo-go util convert deee79c189f30098b0ba6a2eb90b3a9258a6c7ff +$ ./bin/tutus util convert deee79c189f30098b0ba6a2eb90b3a9258a6c7ff BE ScriptHash to Address NgEisvCqr2h8wpRxQb7bVPWUZdbVCY8Uo6 LE ScriptHash to Address NjEQfanGEXihz85eTnacQuhqhNnA6LxpLp Hex to String "\xde\xeey\xc1\x89\xf3\x00\x98\xb0\xbaj.\xb9\v:\x92X\xa6\xc7\xff" @@ -642,7 +642,7 @@ like `wallet nep17 transfer` or `contract invokefunction` can give you one with the `--out` parameter) you may want to check the contents before signing it. This can be done with the `util txdump` command: ``` -$ ./bin/neo-go util txdump -r http://localhost:30333 some.part.json +$ ./bin/tutus util txdump -r http://localhost:30333 some.part.json Hash: f143059e0c03546db006608e0a0ad4b621b311a48d7fc62bb7062e405ab8e588 OnChain: false ValidUntil: 6004 @@ -701,7 +701,7 @@ If you have a completely finished (with all signatures collected) transaction signing context saved in a file you can send it to the network (without any wallet) using `util sendtx` command: ``` -$ ./bin/neo-go util sendtx -r http://localhost:30333 some.part.json +$ ./bin/tutus util sendtx -r http://localhost:30333 some.part.json ``` This is useful in offline signing scenario, where the signing party doesn't have any network access, so you can make a signature there, transfer the file @@ -712,12 +712,12 @@ to the network. There is a VM CLI that you can use to load/analyze/run/step through some code: ``` -./bin/neo-go vm +./bin/tutus vm ``` Some basic commands available there: -- `loadgo` -- loads smart contract `NEO-GO-VM > loadgo TestContract/main.go` +- `loadgo` -- loads smart contract `TUTUS-VM > loadgo TestContract/main.go` - `ops` -- show the opcodes of currently loaded contract - `run` -- executes currently loaded contract diff --git a/docs/compiler.md b/docs/compiler.md index 286d90b..d95adc9 100644 --- a/docs/compiler.md +++ b/docs/compiler.md @@ -1,6 +1,6 @@ -# NeoGo smart contract compiler +# Tutus smart contract compiler -The neo-go compiler compiles Go programs to a bytecode that the Neo virtual machine can understand. +The tutus compiler compiles Go programs to a bytecode that the Neo virtual machine can understand. ## Language compatibility @@ -69,7 +69,7 @@ export GOROOT=/usr/lib64/go/1.15 The best way to create a new contract is to use `contract init` command. This will create an example source file, a config file and `go.mod` with `github.com/tutus-one/tutus-chain/pkg/interop` dependency. ``` -$ ./bin/neo-go contract init --name MyAwesomeContract +$ ./bin/tutus contract init --name MyAwesomeContract $ cd MyAwesomeContract ``` @@ -82,7 +82,7 @@ $ go mod tidy ### Compiling ``` -./bin/neo-go contract compile -i contract.go +./bin/tutus contract compile -i contract.go ``` By default, the filename will be the name of your .go file with the .nef @@ -98,21 +98,21 @@ All of them will be located in the same directory with your Go contract. If you want another location for your compiled contract: ``` -./bin/neo-go contract compile -i contract.go --out /Users/foo/bar/contract.nef +./bin/tutus contract compile -i contract.go --out /Users/foo/bar/contract.nef ``` If your contract is split across multiple files, you must provide a path to the directory where package files are contained instead of a single Go file (`out.nef` will be used as the default output file in this case): ``` -./bin/neo-go contract compile -i ./path/to/contract +./bin/tutus contract compile -i ./path/to/contract ``` ### Debugging You can dump the opcodes generated by the compiler with the following command: ``` -./bin/neo-go contract inspect -i contract.go -c +./bin/tutus contract inspect -i contract.go -c ``` This will result in something like this: @@ -219,7 +219,7 @@ Toolkit](https://github.com/neo-project/neo-blockchain-toolkit/). To do that you need to generate debug information using `--debug` option, like this: ``` -$ ./bin/neo-go contract compile -i contract.go -c contract.yml -m contract.manifest.json -o contract.nef --debug contract.debug.json +$ ./bin/tutus contract compile -i contract.go -c contract.yml -m contract.manifest.json -o contract.nef --debug contract.debug.json ``` This file can then be used by debugger and set up to work just like for any @@ -227,12 +227,12 @@ other supported language. ### Deploying -Deploying a contract to blockchain with neo-go requires both NEF and JSON +Deploying a contract to blockchain with tutus requires both NEF and JSON manifest generated by the compiler from a configuration file provided in YAML format. To create contract manifest, pass a YAML file with `-c` parameter and specify the manifest output file with `-m`: ``` -./bin/neo-go contract compile -i contract.go -c config.yml -m contract.manifest.json +./bin/tutus contract compile -i contract.go -c config.yml -m contract.manifest.json ``` Example of such YAML file contents: @@ -250,7 +250,7 @@ events: Then, the manifest can be passed to the `deploy` command via `-m` option: ``` -$ ./bin/neo-go contract deploy -i contract.nef -m contract.manifest.json -r http://localhost:20331 -w wallet.json +$ ./bin/tutus contract deploy -i contract.nef -m contract.manifest.json -r http://localhost:20331 -w wallet.json ``` Deployment works via an RPC server, an address of which is passed via `-r` @@ -264,7 +264,7 @@ the manifest, and the target contract hash. Either NEF file or the manifest may be omitted, but not both. Additional data parameter may be specified. ``` -$ ./bin/neo-go contract update -i contract.nef -m contract.manifest.json -r http://localhost:20331 -w wallet.json 0x4bfd65abeac8f85931f2d85cfdbc61de3dd03b94 +$ ./bin/tutus contract update -i contract.nef -m contract.manifest.json -r http://localhost:20331 -w wallet.json 0x4bfd65abeac8f85931f2d85cfdbc61de3dd03b94 ``` Updating works via an RPC server, an address of which is passed via `-r` @@ -276,7 +276,7 @@ be found in `update` command help. Destroying a deployed smart contract. Requires the contract hash. ```bash -$ ./bin/neo-go contract destroy -r http://localhost:20331 -w wallet.json 0x4bfd65abeac8f85931f2d85cfdbc61de3dd03b94 +$ ./bin/tutus contract destroy -r http://localhost:20331 -w wallet.json 0x4bfd65abeac8f85931f2d85cfdbc61de3dd03b94 ``` Destroying works via an RPC server, an address of which is passed via `-r` @@ -409,7 +409,7 @@ It requires a divisible NFT contract to have 2 `transfer` methods. To achieve th Any contract can be included in a group identified by a public key which is used in [permissions](#Permissions). This is achieved with `manifest add-group` command. ``` -./bin/neo-go contract manifest add-group -n contract.nef -m contract.manifest.json --sender --wallet /path/to/wallet.json --account +./bin/tutus contract manifest add-group -n contract.nef -m contract.manifest.json --sender --wallet /path/to/wallet.json --account ``` It accepts contract `.nef` and manifest files emitted by `compile` command as well as sender and signer accounts. `--sender` is the account that will send deploy transaction later (not necessarily in wallet). @@ -422,12 +422,12 @@ Express](https://github.com/neo-project/neo-express), which is a part of [Neo Blockchain Toolkit](https://github.com/neo-project/neo-blockchain-toolkit/). To do that, you need to generate a different metadata file using YAML written for -deployment with neo-go. It's done in the same step with compilation via +deployment with tutus. It's done in the same step with compilation via `--config` input parameter and `--abi` output parameter, combined with debug support the command line will look like this: ``` -$ ./bin/neo-go contract compile -i contract.go --config contract.yml -o contract.nef --debug contract.debug.json --abi contract.abi.json +$ ./bin/tutus contract compile -i contract.go --config contract.yml -o contract.nef --debug contract.debug.json --abi contract.abi.json ``` This file can then be used by toolkit to deploy contract the same way @@ -448,20 +448,20 @@ Example call (contract `f84d6a337fbc3d3a201d41da99e86b479e7a2554` with method given RPC server and wallet and paying 0.00001 extra GAS for this transaction): ``` -$ ./bin/neo-go contract invokefunction -r http://localhost:20331 -w my_wallet.json -g 0.00001 f84d6a337fbc3d3a201d41da99e86b479e7a2554 balanceOf NVTiAjNgagDkTr5HTzDmQP9kPwPHN5BgVq +$ ./bin/tutus contract invokefunction -r http://localhost:20331 -w my_wallet.json -g 0.00001 f84d6a337fbc3d3a201d41da99e86b479e7a2554 balanceOf NVTiAjNgagDkTr5HTzDmQP9kPwPHN5BgVq ``` ### Generating contract bindings To be able to use deployed contract from another contract one needs to have its interface definition (exported methods and hash). While it is possible to use generic contract.Call interop interface, it's not very convenient and -efficient. NeoGo can autogenerate contract bindings in Go language for any +efficient. Tutus can autogenerate contract bindings in Go language for any deployed contract based on its manifest, it creates a Go source file with all of the contract's methods that then can be imported and used as a regular Go package. ``` -$ ./bin/neo-go contract generate-wrapper --manifest manifest.json --out wrapper.go --hash 0x1b4357bff5a01bdf2a6581247cf9ed1e24629176 +$ ./bin/tutus contract generate-wrapper --manifest manifest.json --out wrapper.go --hash 0x1b4357bff5a01bdf2a6581247cf9ed1e24629176 ``` Notice that some structured types can be omitted this way (when a function @@ -471,8 +471,8 @@ originally you can create a specific configuration file during compilation that will add this data for wrapper generator to use: ``` -$ ./bin/neo-go contract compile -i contract.go --config contract.yml -o contract.nef --manifest manifest.json --bindings contract.bindings.yml -$ ./bin/neo-go contract generate-wrapper --manifest manifest.json --config contract.bindings.yml --out wrapper.go --hash 0x1b4357bff5a01bdf2a6581247cf9ed1e24629176 +$ ./bin/tutus contract compile -i contract.go --config contract.yml -o contract.nef --manifest manifest.json --bindings contract.bindings.yml +$ ./bin/tutus contract generate-wrapper --manifest manifest.json --config contract.bindings.yml --out wrapper.go --hash 0x1b4357bff5a01bdf2a6581247cf9ed1e24629176 ``` ### Generating RPC contract bindings @@ -488,7 +488,7 @@ type, in this case an ASSERT is added to script making it fail when the method returns false. ``` -$ ./bin/neo-go contract generate-rpcwrapper --manifest manifest.json --out rpcwrapper.go --hash 0x1b4357bff5a01bdf2a6581247cf9ed1e24629176 +$ ./bin/tutus contract generate-rpcwrapper --manifest manifest.json --out rpcwrapper.go --hash 0x1b4357bff5a01bdf2a6581247cf9ed1e24629176 ``` If your contract is NEP-11 or NEP-17 that's autodetected and an appropriate @@ -505,8 +505,8 @@ and structures. Notice that structured types returned by methods can't be Null at the moment (see #2795). ``` -$ ./bin/neo-go contract compile -i contract.go --config contract.yml -o contract.nef --manifest manifest.json --bindings contract.bindings.yml --guess-eventtypes -$ ./bin/neo-go contract generate-rpcwrapper --manifest manifest.json --config contract.bindings.yml --out rpcwrapper.go --hash 0x1b4357bff5a01bdf2a6581247cf9ed1e24629176 +$ ./bin/tutus contract compile -i contract.go --config contract.yml -o contract.nef --manifest manifest.json --bindings contract.bindings.yml --guess-eventtypes +$ ./bin/tutus contract generate-rpcwrapper --manifest manifest.json --config contract.bindings.yml --out rpcwrapper.go --hash 0x1b4357bff5a01bdf2a6581247cf9ed1e24629176 ``` Contract-specific RPC-bindings generated by "generate-rpcwrapper" command include diff --git a/docs/consensus.md b/docs/consensus.md index 603222b..be72aaa 100644 --- a/docs/consensus.md +++ b/docs/consensus.md @@ -1,6 +1,6 @@ -# NeoGo consensus node +# Tutus consensus node -NeoGo node can act as a consensus node. A consensus node differs from a regular +Tutus node can act as a consensus node. A consensus node differs from a regular one in that it participates in block acceptance process using dBFT protocol. Any committee node can also be elected as a CN; therefore, they're expected to follow the same setup process as CNs (to be ready to become CNs @@ -15,7 +15,7 @@ use some key from some wallet. ### Hardware requirements -While NeoGo can be very conservative with its resource consumption, public +While Tutus can be very conservative with its resource consumption, public network CN provides some service to the general audience and thus should have enough hardware resources to do its job reliably. We recommend amd64 machine with at least two cores, 8+ GB of memory and 64 GB SSD (disk space @@ -25,23 +25,23 @@ be enough for the first year of blockchain). ### OS requirements -NeoGo is a single binary that can be run on any modern GNU/Linux +Tutus is a single binary that can be run on any modern GNU/Linux distribution. We recommend using major well-supported OSes like CentOS, Debian or Ubuntu. Make sure they're updated with the latest security patches. -No additional packages are needed for NeoGo CN. +No additional packages are needed for Tutus CN. ### Installation -Download NeoGo binary [from +Download Tutus binary [from Github](https://github.com/tutus-one/tutus-chain/releases) or use [Docker -image](https://hub.docker.com/r/nspccdev/neo-go). It has everything included, +image](https://hub.docker.com/r/nspccdev/tutus). It has everything included, no additional plugins needed. Take an appropriate (mainnet/testnet) configuration [from the repository](https://github.com/tutus-one/tutus-chain/tree/master/config) and save it in some directory (we'll assume that it's available in the same directory as -neo-go binary). +tutus binary). ### Configuration and execution @@ -58,7 +58,7 @@ where `wallet.json` is a path to your NEP-6 wallet and `welcometotherealworld` is a password to your CN key. Run the node in a regular way after that: ``` -$ neo-go node --mainnet --config-path ./ +$ tutus node --mainnet --config-path ./ ``` where `--mainnet` is your network (can be `--testnet` for testnet) and `--config-path` is a path to the configuration file directory. If the node starts @@ -84,7 +84,7 @@ mode just drop the `UnlockWallet` section from the configuration like this: ### Registration -To register as a candidate, use neo-go as CLI command with an external RPC +To register as a candidate, use tutus as CLI command with an external RPC server for it to connect to (for chain data and transaction submission). You can use any public RPC server or an RPC server of your own like the node started at the previous step. We'll assume that you run the next command on @@ -93,9 +93,9 @@ the same node in default configuration with RPC interface available at port Candidate registration is performed via GAS transfer to native NeoToken contract that costs 1000 GAS by default. You need to provide your wallet and address to -neo-go command: +tutus command: ``` -$ neo-go wallet candidate register -a NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa -w wallet.json -r http://localhost:10332 +$ tutus wallet candidate register -a NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa -w wallet.json -r http://localhost:10332 ``` where `NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa` is your address, `wallet.json` is a path to NEP-6 wallet file and `http://localhost:10332` is an RPC node to @@ -111,7 +111,7 @@ Candidate registration via call to `registerCandidate` method of native NeoToken contract is deprecated starting from Echidna hardfork. To enforce using the deprecated registration behaviour specify `--useRegisterCall` flag. ``` -$ neo-go wallet candidate register -a NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa -w wallet.json -r http://localhost:10332 --useRegisterCall +$ tutus wallet candidate register -a NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa -w wallet.json -r http://localhost:10332 --useRegisterCall ``` ### Voting @@ -123,7 +123,7 @@ you need to know the public key of your candidate, which can either be seen in command: ``` -$ neo-go wallet dump-keys -w wallet.json +$ tutus wallet dump-keys -w wallet.json NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa (simple signature contract): 0363f6678ea4c59e292175c67e2b75c9ba7bb73e47cd97cdf5abaf45de157133f5 ``` @@ -132,7 +132,7 @@ NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa (simple signature contract): public key for `NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa` address. To vote for it use: ``` -$ neo-go wallet candidate vote -a NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa -w wallet.json -r http://localhost:10332 -c 0363f6678ea4c59e292175c67e2b75c9ba7bb73e47cd97cdf5abaf45de157133f5 +$ tutus wallet candidate vote -a NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa -w wallet.json -r http://localhost:10332 -c 0363f6678ea4c59e292175c67e2b75c9ba7bb73e47cd97cdf5abaf45de157133f5 ``` where `NiKEkwz6i9q6gqfCizztDoHQh9r9BtdCNa` is the voter's address, `wallet.json` @@ -141,10 +141,10 @@ is the NEP-6 wallet file path, `http://localhost:10332` is the RPC node address public key the voter votes for. This command also returns transaction hash and you need to wait for this transaction to be accepted into one of subsequent blocks. -## Private NeoGo network +## Private Tutus network ### Using existing Dockerfile -neo-go comes with two preconfigured private network setups, the first one has +tutus comes with two preconfigured private network setups, the first one has four consensus nodes and the second one uses single node. Nodes are packed into Docker containers and four-node setup shares a volume for chain data. @@ -153,7 +153,7 @@ Four-node setup uses ports 20333-20336 for P2P communication and ports 20001-20004). Single-node is on ports 20333/30333/20001 for P2P/RPC/Prometheus. -NeoGo default privnet configuration is made to work with four-node consensus, +Tutus default privnet configuration is made to work with four-node consensus, you have to modify it if you're to use single consensus node. Node wallets are located in the `.docker/wallets` directory where @@ -206,4 +206,4 @@ Examples can be found at `config/protocol.privnet.docker.one.yml` (`two`, `three 4. If you start binary from the same directory, you will probably want to change `DataDirectoryPath` from the `LevelDBOptions`. -3. Start all nodes with `neo-go node --config-path `. +3. Start all nodes with `tutus node --config-path `. diff --git a/docs/neofs-blockstorage.md b/docs/neofs-blockstorage.md index 76bfcd7..39a84d0 100644 --- a/docs/neofs-blockstorage.md +++ b/docs/neofs-blockstorage.md @@ -1,7 +1,7 @@ # NeoFS block storage Using NeoFS to store chain's blocks and snapshots was proposed in -[#3463](https://github.com/neo-project/neo/issues/3463). NeoGo contains several +[#3463](https://github.com/neo-project/neo/issues/3463). Tutus contains several extensions utilizing NeoFS block storage aimed to improve node synchronization efficiency and reduce node storage size. @@ -96,10 +96,10 @@ them to the NeoFS container. The batch size should be consistent from run to run otherwise gaps in the uploaded blocks may occur. Below is an example usage of the command: ```shell -./bin/neo-go util upload-bin --cid 9iVfUg8aDHKjPC4LhQXEkVUM4HDkR7UCXYLs8NQwYfSG --wallet-config ./wallet-config.yml --block-attribute Block --rpc-endpoint https://rpc.t5.n3.nspcc.ru:20331 -fsr st1.t5.fs.neo.org:8080 -fsr st2.t5.fs.neo.org:8080 -fsr st3.t5.fs.neo.org:8080 +./bin/tutus util upload-bin --cid 9iVfUg8aDHKjPC4LhQXEkVUM4HDkR7UCXYLs8NQwYfSG --wallet-config ./wallet-config.yml --block-attribute Block --rpc-endpoint https://rpc.t5.n3.nspcc.ru:20331 -fsr st1.t5.fs.neo.org:8080 -fsr st2.t5.fs.neo.org:8080 -fsr st3.t5.fs.neo.org:8080 ``` -Run `./bin/neo-go util upload-bin --help` to see the full list of supported options. +Run `./bin/tutus util upload-bin --help` to see the full list of supported options. This command works as follows: 1. Fetches the current block height from the RPC node. @@ -151,10 +151,10 @@ smart contract storage, and upload MPT nodes to a NeoFS container at every `StateSyncInterval` number of blocks. Below is an example usage of the command: ```shell -./bin/neo-go util upload-state --cid 9iVfUg8aDHKjPC4LhQXEkVUM4HDkR7UCXYLs8NQwYfSG --wallet-config ./wallet-config.yml --state-attribute State -m -fsr st1.t5.fs.neo.org:8080 -fsr st2.t5.fs.neo.org:8080 -fsr st3.t5.fs.neo.org:8080 +./bin/tutus util upload-state --cid 9iVfUg8aDHKjPC4LhQXEkVUM4HDkR7UCXYLs8NQwYfSG --wallet-config ./wallet-config.yml --state-attribute State -m -fsr st1.t5.fs.neo.org:8080 -fsr st2.t5.fs.neo.org:8080 -fsr st3.t5.fs.neo.org:8080 ``` -Run `./bin/neo-go util upload-state --help` to see the full list of supported options. +Run `./bin/tutus util upload-state --help` to see the full list of supported options. This command works as follows: 1. Searches for the state objects stored in NeoFS to find the latest uploaded object. diff --git a/docs/node-configuration.md b/docs/node-configuration.md index 7c4644f..8a7ece3 100644 --- a/docs/node-configuration.md +++ b/docs/node-configuration.md @@ -1,6 +1,6 @@ -# NeoGo node configuration file +# Tutus node configuration file -This section contains detailed NeoGo node configuration file description +This section contains detailed Tutus node configuration file description including default config values and some tips to set up configurable values. Each config file contains two sections. `ApplicationConfiguration` describes node-related @@ -462,7 +462,7 @@ protocol-related settings described in the table below. | Section | Type | Default value | Description | Notes | | --- | --- | --- | --- | --- | | CommitteeHistory | map[uint32]uint32 | none | Number of committee members after the given height, for example `{0: 1, 20: 4}` sets up a chain with one committee member since the genesis and then changes the setting to 4 committee members at the height of 20. `StandbyCommittee` committee setting must have the number of keys equal or exceeding the highest value in this option. Blocks numbers where the change happens must be divisible by the old and by the new values simultaneously. If not set, committee size is derived from the `StandbyCommittee` setting and never changes. | -| Genesis | [Genesis](#Genesis-Configuration) | none | The set of genesis block settings including NeoGo-specific protocol extensions that should be enabled at the genesis block or during native contracts initialisation. | +| Genesis | [Genesis](#Genesis-Configuration) | none | The set of genesis block settings including Tutus-specific protocol extensions that should be enabled at the genesis block or during native contracts initialisation. | | Hardforks | `map[string]uint32` | [] | The set of incompatible changes that affect node behaviour starting from the specified height. The default value is an empty set which should be interpreted as "each known stable hard-fork is applied from the zero blockchain height". See [Hardforks](#Hardforks) section for a list of supported keys. | | Magic | `uint32` | `0` | Magic number which uniquely identifies Neo network. | | MaxBlockSize | `uint32` | `262144` | Maximum block size in bytes. | @@ -481,7 +481,7 @@ protocol-related settings described in the table below. | StateRootInHeader | `bool` | `false` | Enables storing state root in block header. | Experimental protocol extension! | | StateSyncInterval | `int` | `40000` | The number of blocks between state heights available for MPT state data synchronization. | `P2PStateExchangeExtensions` should be enabled to use this setting. | | TimePerBlock | `Duration` | `15s` | Minimal (and targeted for) time interval between blocks if MaxTimePerBlock is not set. Must be an integer number of milliseconds. This setting is replaced by [`Genesis`-level](#Genesis-Configuration) `TimePerBlock` protocol configuration setting and corresponding Policy value starting from `Echidna` hardfork. | -| MaxTimePerBlock | `Duration` | `0s` | Maximum (and targeted for) time interval between blocks for cases when there's no transactions in the node's memory pool. Must be an integer number of milliseconds. If set, time interval between blocks will vary from TimePerBlock (when there are some transactions in the network) and MaxTimePerBlock. | An extension of NeoGo node that enables dynamic block time as described in https://github.com/neo-project/neo/issues/4018. | +| MaxTimePerBlock | `Duration` | `0s` | Maximum (and targeted for) time interval between blocks for cases when there's no transactions in the node's memory pool. Must be an integer number of milliseconds. If set, time interval between blocks will vary from TimePerBlock (when there are some transactions in the network) and MaxTimePerBlock. | An extension of Tutus node that enables dynamic block time as described in https://github.com/neo-project/neo/issues/4018. | | ValidatorsCount | `uint32` | `0` | Number of validators set for the whole network lifetime, can't be set if `ValidatorsHistory` setting is used. | | ValidatorsHistory | map[uint32]uint32 | none | Number of consensus nodes to use after given height (see `CommitteeHistory` also). Heights where the change occurs must be divisible by the number of committee members at that height. Can't be used with `ValidatorsCount` not equal to zero. Initial validators count for genesis block must always be specified. | | VerifyTransactions | `bool` | `false` | Denotes whether to verify transactions in the received blocks. | @@ -489,7 +489,7 @@ protocol-related settings described in the table below. ### Genesis Configuration `Genesis` subsection of protocol configuration section contains a set of settings -specific for genesis block including NeoGo node extensions that should be enabled +specific for genesis block including Tutus node extensions that should be enabled during genesis block persist or at the moment of native contracts initialisation. This subsection also contains initial values used for native Policy contract storage initialisation at Echidna hardfork. `Genesis` has the following structure: @@ -543,7 +543,7 @@ where: Roles designation order follows the enumeration above. Designation notifications will be emitted after each configured role designation. - Note that Roles is a NeoGo extension that isn't supported by the NeoC# node and + Note that Roles is a Tutus extension that isn't supported by the NeoC# node and must be disabled on the public Neo N3 networks. Roles extension is compatible with Hardforks setting, which means that specified roles will be set only during native RoleManagement contract initialisation (which may be @@ -568,7 +568,7 @@ where: signer and the second one (if differs from the first) is committee multisignature signer. - Note that `Transaction` is a NeoGo extension that isn't supported by the NeoC# + Note that `Transaction` is a Tutus extension that isn't supported by the NeoC# node and must be disabled on the public Neo N3 networks. ### Hardforks @@ -578,10 +578,10 @@ in development and can change in an incompatible way. | Name | Changes | References | | --- | --- | --- | -| `Aspidochelone` | Adjusts the price of `System.Contract.CreateStandardAccount` and `System.Contract.CreateMultisigAccount` interops so that the resulting prices are in accordance with `sha256` method of native `CryptoLib` contract. Also adjusts the price of `System.Runtime.GetRandom` interop and fixes its vulnerability. A special NeoGo-specific change is included as well for ContractManagement's update/deploy call flags behaviour to be compatible with pre-0.99.0 behaviour that was changed because of the 3.2.0 protocol change | https://github.com/tutus-one/tutus-chain/pull/2469
https://github.com/neo-project/neo/pull/2712
https://github.com/tutus-one/tutus-chain/pull/2519
https://github.com/neo-project/neo/pull/2749
https://github.com/neo-project/neo/pull/2653 | +| `Aspidochelone` | Adjusts the price of `System.Contract.CreateStandardAccount` and `System.Contract.CreateMultisigAccount` interops so that the resulting prices are in accordance with `sha256` method of native `CryptoLib` contract. Also adjusts the price of `System.Runtime.GetRandom` interop and fixes its vulnerability. A special Tutus-specific change is included as well for ContractManagement's update/deploy call flags behaviour to be compatible with pre-0.99.0 behaviour that was changed because of the 3.2.0 protocol change | https://github.com/tutus-one/tutus-chain/pull/2469
https://github.com/neo-project/neo/pull/2712
https://github.com/tutus-one/tutus-chain/pull/2519
https://github.com/neo-project/neo/pull/2749
https://github.com/neo-project/neo/pull/2653 | | `Basilisk` | Enables strict smart contract script check against a set of JMP instructions and against method boundaries enabled on contract deploy or update. Increases `stackitem.Integer` JSON parsing precision up to the maximum value supported by the NeoVM. Enables strict check for notifications emitted by a contract to precisely match the events specified in the contract manifest. | https://github.com/tutus-one/tutus-chain/pull/3056
https://github.com/neo-project/neo/pull/2881
https://github.com/tutus-one/tutus-chain/pull/3080
https://github.com/neo-project/neo/pull/2883
https://github.com/tutus-one/tutus-chain/pull/3085
https://github.com/neo-project/neo/pull/2810 | | `Cockatrice` | Introduces the ability to update native contracts. Includes a couple of new native smart contract APIs: `keccak256` of native CryptoLib contract and `getCommitteeAddress` of native NeoToken contract. | https://github.com/tutus-one/tutus-chain/pull/3402
https://github.com/neo-project/neo/pull/2942
https://github.com/tutus-one/tutus-chain/pull/3301
https://github.com/neo-project/neo/pull/2925
https://github.com/tutus-one/tutus-chain/pull/3362
https://github.com/neo-project/neo/pull/3154 | -| `Domovoi` | Makes node use executing contract state for the contract call permissions check instead of the state stored in the native Management contract. In C# also makes System.Runtime.GetNotifications interop properly count stack references of notification parameters which prevents users from creating objects that exceed MaxStackSize constraint, but NeoGo has never had this bug, thus proper behaviour is preserved even before HFDomovoi. It results in the fact that some T5 testnet transactions have different ApplicationLogs compared to the C# node, but the node states match. | https://github.com/tutus-one/tutus-chain/pull/3476
https://github.com/neo-project/neo/pull/3290
https://github.com/tutus-one/tutus-chain/pull/3473
https://github.com/neo-project/neo/pull/3290
https://github.com/neo-project/neo/pull/3301
https://github.com/tutus-one/tutus-chain/pull/3485 | +| `Domovoi` | Makes node use executing contract state for the contract call permissions check instead of the state stored in the native Management contract. In C# also makes System.Runtime.GetNotifications interop properly count stack references of notification parameters which prevents users from creating objects that exceed MaxStackSize constraint, but Tutus has never had this bug, thus proper behaviour is preserved even before HFDomovoi. It results in the fact that some T5 testnet transactions have different ApplicationLogs compared to the C# node, but the node states match. | https://github.com/tutus-one/tutus-chain/pull/3476
https://github.com/neo-project/neo/pull/3290
https://github.com/tutus-one/tutus-chain/pull/3473
https://github.com/neo-project/neo/pull/3290
https://github.com/neo-project/neo/pull/3301
https://github.com/tutus-one/tutus-chain/pull/3485 | | `Echidna` | Introduces `Designation` event extension with `Old` and `New` roles data to native RoleManagement contract. Adds support for `base64UrlEncode` and `base64UrlDecode` methods to native StdLib contract. Extends the list of required call flags for `registerCandidate`, `unregisterCandidate`and `vote` methods of native NeoToken contract with AllowNotify flag. Enables `onNEP17Payment` method of NEO contract for candidate registration. Introduces constraint for maximum number of execution notifications. Adds support for `recoverSecp256K1` method of native CryptoLib contract. Introduces `setMillisecondsPerBlock` and `getMillisecondsPerBlock` methods of native Policy contract. Introduces support for NotaryAssisted transaction attribute and native Notary contract. | https://github.com/tutus-one/tutus-chain/pull/3554
https://github.com/tutus-one/tutus-chain/pull/3761
https://github.com/tutus-one/tutus-chain/pull/3554
https://github.com/neo-project/neo/pull/3597
https://github.com/tutus-one/tutus-chain/pull/3700
https://github.com/tutus-one/tutus-chain/pull/3640
https://github.com/neo-project/neo/pull/3548
https://github.com/tutus-one/tutus-chain/pull/3863
https://github.com/neo-project/neo/pull/3696
https://github.com/neo-project/neo/pull/3895
https://github.com/tutus-one/tutus-chain/pull/3835
https://github.com/tutus-one/tutus-chain/pull/3854
https://github.com/neo-project/neo/pull/3175
https://github.com/tutus-one/tutus-chain/pull/3478
https://github.com/neo-project/neo/pull/3178 | | `Faun` | Adds `getBlockedAccounts` method to native Policy contract. Adds `hexEncode` and `hexDecode` methods to native StdLib contract. Adds `getExecPicoFeeFactor` method to native Policy contract and enables 4 decimals for execution fee factor. Adds whitelist fee contract management to native Policy contract: `setWhitelistFeeContract`, `removeWhitelistFeeContract`, `getWhitelistFeeContracts` methods and `WhitelistFeeChanged` event. | https://github.com/tutus-one/tutus-chain/pull/3932
https://github.com/tutus-one/tutus-chain/pull/4004
https://github.com/neo-project/neo/pull/4147
https://github.com/neo-project/neo/pull/4150
https://github.com/tutus-one/tutus-chain/pull/4057
https://github.com/neo-project/neo/pull/4278
https://github.com/tutus-one/tutus-chain/pull/4052
https://github.com/neo-project/neo/pull/4201 | @@ -591,7 +591,7 @@ Real networks with large number of blocks require a substantial amount of time to synchronize. When operating a number of node instances with similar configurations you may want to save some resources by performing synchronization on one node and then copying the DB over to other instances. In general, this -can be done and this is supported, but NeoGo has a lot of options that may +can be done and this is supported, but Tutus has a lot of options that may affect this: - any differences in `ProtocolConfiguration` section make (or may make) databases incompatible, except for `MemPoolSize`, `P2PNotaryRequestPayloadPoolSize`, diff --git a/docs/notary.md b/docs/notary.md index 4f11ee8..de2dba3 100644 --- a/docs/notary.md +++ b/docs/notary.md @@ -1,6 +1,6 @@ -# NeoGo P2P signature collection (notary) service +# Tutus P2P signature collection (notary) service -P2P signature (notary) service is a NeoGo node extension that allows several +P2P signature (notary) service is a Tutus node extension that allows several parties to sign one transaction independently of chain and without going beyond the chain environment. The on-chain P2P service is aimed to automate, accelerate and secure the process of signature collection. The service was initially designed as @@ -138,27 +138,27 @@ associated fallback transactions for the main transaction. After processing, service request is deleted from the module. -See the [NeoGo P2P signature extensions](#NeoGo P2P signature extensions) on how +See the [Tutus P2P signature extensions](#Tutus P2P signature extensions) on how to enable notary-related extensions on chain and -[NeoGo Notary service node module](#NeoGo Notary service node module) on how to +[Tutus Notary service node module](#Tutus Notary service node module) on how to set up Notary service node. ## Environment setup To run P2P signature collection service on your network, you need to do: -* Set up [`P2PSigExtensions`](#NeoGo P2P signature extensions) for all nodes in +* Set up [`P2PSigExtensions`](#Tutus P2P signature extensions) for all nodes in the network. * Set notary node keys in `RoleManagement` native contract. -* [Configure](#NeoGo Notary service node module) and run appropriate number of +* [Configure](#Tutus Notary service node module) and run appropriate number of notary nodes with keys specified in `RoleManagement` native contract (at least one node is necessary to complete signature collection). After service is running, you can [create and send](#Notary request lifecycle guide) notary requests to the network. -### NeoGo P2P signature extensions +### Tutus P2P signature extensions -As far as Notary service is an extension of the standard NeoGo node, it should be +As far as Notary service is an extension of the standard Tutus node, it should be enabled and properly configured before usage. #### Configuration @@ -177,7 +177,7 @@ set to 0 (if `P2PSigExtensions` are enabled). Note, that even if `P2PSigExtensions` config subsection enables notary-related logic in the network, it still does not turn your node into notary service node. To enable notary service node functionality refer to the -[NeoGo Notary service](#NeoGo-Notary-service-node-module) documentation. +[Tutus Notary service](#Tutus-Notary-service-node-module) documentation. ##### Example @@ -186,9 +186,9 @@ To enable notary service node functionality refer to the ``` -### NeoGo Notary service node module +### Tutus Notary service node module -NeoGo node can act as notary service node (the node that accumulates notary +Tutus node can act as notary service node (the node that accumulates notary requests, collects signatures and releases fully-signed transactions). It must have a wallet with a key belonging to one of network's designated notary nodes (stored in `RoleManagement` native contract). Also, the node must be connected to @@ -203,7 +203,7 @@ to the notary service node and avoid P2P communication delays. #### Configuration To enable notary service node check firstly that -[P2PSignatureExtensions](#NeoGo P2P signature extensions) are properly set up. +[P2PSignatureExtensions](#Tutus P2P signature extensions) are properly set up. Then add `P2PNotary` subsection to `ApplicationConfiguration` section of your node config. @@ -284,7 +284,7 @@ server via [`submitnotaryrequest` RPC call](./rpc.md#submitnotaryrequest-call). Note, that all parties must generate the same main transaction while fallbacks can differ. -To create a notary request, you can use [NeoGo RPC client](./rpc.md#Client). The +To create a notary request, you can use [Tutus RPC client](./rpc.md#Client). The procedure below uses only basic RPC client functions and show all of the notary request internals. You can use much simpler Actor interface in the notary subpackage with an example written in Go doc. @@ -413,7 +413,7 @@ is highly likely to be a part of `H+1` block. Once the P2PNotaryRequest reaches RPC node, it is added to the notary request pool. Completed or outdated requests are removed from the pool. Use -[NeoGo notification subsystem](./notifications.md) to track request addition and +[Tutus notification subsystem](./notifications.md) to track request addition and removal: - Use RPC `subscribe` method with `notary_request_event` stream name parameter to diff --git a/docs/oracle.md b/docs/oracle.md index 8b55b0f..c4b0c85 100644 --- a/docs/oracle.md +++ b/docs/oracle.md @@ -1,6 +1,6 @@ -# NeoGo Oracle service +# Tutus Oracle service -NeoGo node can act as an oracle service node for https and neofs protocols. It +Tutus node can act as an oracle service node for https and neofs protocols. It has to have a wallet with a key belonging to one of the network's designated oracle nodes (stored in `RoleManagement` native contract). diff --git a/docs/release-instruction.md b/docs/release-instruction.md index 2ccc0f4..aec3164 100644 --- a/docs/release-instruction.md +++ b/docs/release-instruction.md @@ -1,6 +1,6 @@ # Release instructions -This document outlines the neo-go release process. It can be used as a todo +This document outlines the tutus release process. It can be used as a todo list for a new release. ## Check the state @@ -21,7 +21,7 @@ describing the most significant changes done in this release. In case if the nod configuration was changed, some API was marked as deprecated, any experimental changes were made in the user-facing code and the users' feedback is needed or if there's any other information that requires user's response, write -another separate paragraph for those who owns NeoGo node or uses any external +another separate paragraph for those who owns Tutus node or uses any external API. Then, add sections with release content describing each change in detail and with a reference to GitHub issues and/or PRs. Minor issues that doesn't affect the node end-user may be grouped under a single label. @@ -60,8 +60,8 @@ start them manually from the Build GitHub workflow), so wait for them to finish. Built binaries should be automatically attached to the release as an asset, check it on the release page. If binaries weren't attached after building workflow completion, then submit the bug, download currently supported binaries -(at the time of writing they are `neo-go-darwin-arm64`, `neo-go-linux-amd64`, -`neo-go-linux-arm64` and `neo-go-windows-amd64`) from the building job artifacts, +(at the time of writing they are `tutus-darwin-arm64`, `tutus-linux-amd64`, +`tutus-linux-arm64` and `tutus-windows-amd64`) from the building job artifacts, unpack archives and add resulting binaries (named in the same way as archives) to the previously created release via "Edit release" button. diff --git a/docs/rpc.md b/docs/rpc.md index 848a054..6450e05 100644 --- a/docs/rpc.md +++ b/docs/rpc.md @@ -22,7 +22,7 @@ which would yield the response: ```json { "result" : { - "useragent" : "/NEO-GO:0.97.2/", + "useragent" : "/TUTUS:0.97.2/", "tcpport" : 10333, "network" : 860833102, "nonce" : 105745208 @@ -85,7 +85,7 @@ which would yield the response: C# implementation contains a number of enumerations and while it outputs them into JSON as comma-separated strings (or just strings if only one value is allowed for this type) it accepts pure numbers for input (see #2563 for -example). NeoGo currently doesn't support this behavior. This affects the +example). Tutus currently doesn't support this behavior. This affects the following data types: * transaction attribute type * oracle response code @@ -101,17 +101,17 @@ Any call that takes any of these types for input in JSON format is affected. ##### Response error codes -NeoGo currently uses a different set of error codes in comparison to C# implementation, see +Tutus currently uses a different set of error codes in comparison to C# implementation, see [proposal](https://github.com/neo-project/proposals/pull/156). -NeoGo retains certain deprecated error codes, which will be removed once +Tutus retains certain deprecated error codes, which will be removed once all nodes adopt the new error standard. ##### `calculatenetworkfee` -NeoGo tries to cover more cases with its calculatenetworkfee implementation, +Tutus tries to cover more cases with its calculatenetworkfee implementation, whereas C# node support only standard signature contracts and deployed contracts that can execute `verify` successfully on incomplete (not yet signed -properly) transaction, NeoGo also works with deployed contracts that fail at +properly) transaction, Tutus also works with deployed contracts that fail at this stage and executes non-standard contracts (that can fail too). It's ignoring the result of any verification script (since the method calculates fee and doesn't care about transaction validity). Invocation script @@ -123,7 +123,7 @@ neo-project/neo#2805 as well. ##### `invokefunction`, `invokescript` -neo-go implementation of `invokefunction` does not return `tx` +tutus implementation of `invokefunction` does not return `tx` field in the answer because that requires signing the transaction with some key in the server, which doesn't fit the model of our node-client interactions. If this signature is lacking, the transaction is almost useless, so there is no point @@ -162,19 +162,19 @@ a native contract by its name (case-insensitive), unlike the C# node where it only possible for index or hash. ##### `getnep11balances` and `getnep17balances` -neo-go implementation of `getnep11balances` and `getnep17balances` does not +tutus implementation of `getnep11balances` and `getnep17balances` does not perform tracking of NEP-11 and NEP-17 balances for each account as it is done -in the C# node. Instead, a neo-go node maintains a list of standard-compliant +in the C# node. Instead, a tutus node maintains a list of standard-compliant contracts, i.e. those contracts that have `NEP-11` or `NEP-17` declared in the supported standards section of the manifest. Each time balances are queried, -the neo-go node asks every NEP-11/NEP-17 contract for the account balance by +the tutus node asks every NEP-11/NEP-17 contract for the account balance by invoking `balanceOf` method with the corresponding args. Invocation GAS limit is set to be 3 GAS. All non-zero balances are included in the RPC call result. Thus, if a token contract doesn't have proper standard declared in the list of supported standards but emits compliant NEP-11/NEP-17 `Transfer` notifications, the token balance won't be shown in the list of balances -returned by the neo-go node (unlike the C# node behavior). However, transfer +returned by the tutus node (unlike the C# node behavior). However, transfer logs of such tokens are still available via respective `getnepXXtransfers` RPC calls. @@ -187,33 +187,33 @@ all tokens of the same asset. ##### `getversion` -NeoGo can return additional fields in the `protocol` object depending on the +Tutus can return additional fields in the `protocol` object depending on the extensions enabled. Specifically that's `p2psigextensions` and `staterootinheader` booleans and `committeehistory` and `validatorshistory` objects (that are effectively maps from stringified integers to other integers). These fields are only returned when corresponding settings are -enabled in the server's protocol configuration. NeoGo can return an additional +enabled in the server's protocol configuration. Tutus can return an additional `application` object depending on the extensions enabled which contains three fields: `saveinvocations`, `keeponlylateststate` and `removeuntraceableblocks` booleans. These fields are only returned when corresponding settings are enabled in the node's application configuration. ##### `getnep11transfers` and `getnep17transfers` -`transfernotifyindex` is not tracked by NeoGo, thus this field is always zero. +`transfernotifyindex` is not tracked by Tutus, thus this field is always zero. ##### `traverseiterator` and `terminatesession` -NeoGo returns an error when it is unable to find a session or iterator, unlike +Tutus returns an error when it is unable to find a session or iterator, unlike the error-free C# response that provides a default result. ##### `verifyProof` -NeoGo can generate an error in response to an invalid proof, unlike +Tutus can generate an error in response to an invalid proof, unlike the error-free C# implementation. ##### `getPeers` -NeoGo extends the `getpeers` RPC call to return the user agent +Tutus extends the `getpeers` RPC call to return the user agent (`useragent` JSON field) and last known block height (`lastknownheight` JSON field) for each connected peer where available. The last known block height field may be stale depending on the @@ -227,19 +227,19 @@ and we're not accepting issues related to them. | Method | Reason | | ------- | ------------| -| `canceltransaction` | Doesn't fit neo-go wallet model, use CLI to do that (`neo-go util canceltx`) | -| `closewallet` | Doesn't fit neo-go wallet model | +| `canceltransaction` | Doesn't fit tutus wallet model, use CLI to do that (`tutus util canceltx`) | +| `closewallet` | Doesn't fit tutus wallet model | | `dumpprivkey` | Shouldn't exist for security reasons, see `closewallet` comment also | | `getnewaddress` | See `closewallet` comment, use CLI to do that | | `getwalletbalance` | See `closewallet` comment, use `getnep17balances` for that | | `getwalletunclaimedgas` | See `closewallet` comment, use `getunclaimedgas` for that | -| `importprivkey` | Not applicable to neo-go, see `closewallet` comment | -| `listaddress` | Not applicable to neo-go, see `closewallet` comment | -| `listplugins` | neo-go doesn't have any plugins, so it makes no sense | -| `openwallet` | Doesn't fit neo-go wallet model | -| `sendfrom` | Not applicable to neo-go, see `openwallet` comment | -| `sendmany` | Not applicable to neo-go, see `openwallet` comment | -| `sendtoaddress` | Not applicable to neo-go, see `claimgas` comment | +| `importprivkey` | Not applicable to tutus, see `closewallet` comment | +| `listaddress` | Not applicable to tutus, see `closewallet` comment | +| `listplugins` | tutus doesn't have any plugins, so it makes no sense | +| `openwallet` | Doesn't fit tutus wallet model | +| `sendfrom` | Not applicable to tutus, see `openwallet` comment | +| `sendmany` | Not applicable to tutus, see `openwallet` comment | +| `sendtoaddress` | Not applicable to tutus, see `claimgas` comment | ### Extensions diff --git a/docs/stateroots.md b/docs/stateroots.md index 7930fa3..10fe73a 100644 --- a/docs/stateroots.md +++ b/docs/stateroots.md @@ -1,9 +1,9 @@ -# NeoGo state validation +# Tutus state validation -NeoGo supports state validation using N3 stateroots and can also act as state +Tutus supports state validation using N3 stateroots and can also act as state validator (run state validation service). -All NeoGo nodes always calculate MPT root hash for data stored by contracts. +All Tutus nodes always calculate MPT root hash for data stored by contracts. Unlike in Neo Legacy, this behavior can't be turned off. They also process stateroot messages broadcasted through the network and save validated signatures from them if the state root hash specified there matches the one signed @@ -43,7 +43,7 @@ To run state validation service on your network you need to: ## StateRootInHeader option -NeoGo also supports protocol extension to include state root hashes right into +Tutus also supports protocol extension to include state root hashes right into header blocks. It's not compatible with regular Neo N3 state validation service and it's not compatible with public Neo N3 networks, but you can use it on private networks if needed. diff --git a/docs/vm.md b/docs/vm.md index e4bf951..1514232 100644 --- a/docs/vm.md +++ b/docs/vm.md @@ -1,10 +1,10 @@ -# NEO-GO-VM +# TUTUS-VM A cross platform virtual machine implementation for `NEF` compatible programs. # Installation -VM is provided as a part of neo-go binary, so usual neo-go build instructions +VM is provided as a part of tutus binary, so usual tutus build instructions are applicable. # Running the VM @@ -12,7 +12,7 @@ are applicable. Start the virtual machine: ``` -$ ./bin/neo-go vm +$ ./bin/tutus vm _ ____________ __________ _ ____ ___ / | / / ____/ __ \ / ____/ __ \ | | / / |/ / @@ -21,7 +21,7 @@ $ ./bin/neo-go vm /_/ |_/_____/\____/ \____/\____/ |___/_/ /_/ -NEO-GO-VM > +TUTUS-VM > ``` # Usage @@ -34,7 +34,7 @@ NEO-GO-VM > /_/ |_/_____/\____/ \____/\____/ |___/_/ /_/ -NEO-GO-VM > help +TUTUS-VM > help Commands: aslot Show arguments slot contents @@ -66,7 +66,7 @@ You can get help for each command and its parameters adding `help` as a parameter to the command: ``` -NEO-GO-VM > step help +TUTUS-VM > step help Usage: step [] is optional parameter to specify number of instructions to run, example: @@ -79,14 +79,14 @@ Usage: step [] To load an avm script in NEF format into the VM: ``` -NEO-GO-VM > loadnef ../contract.nef +TUTUS-VM > loadnef ../contract.nef READY: loaded 36 instructions ``` Run the script: ``` -NEO-GO-VM > run +TUTUS-VM > run [ { "value": 1, @@ -98,16 +98,16 @@ NEO-GO-VM > run You can also directly compile and load `.go` files: ``` -NEO-GO-VM > loadgo ../contract.go +TUTUS-VM > loadgo ../contract.go READY: loaded 36 instructions ``` To make it even more complete, you can directly load hex or base64 strings into the VM: ``` -NEO-GO-VM > loadhex 0c0c48656c6c6f20776f726c6421 +TUTUS-VM > loadhex 0c0c48656c6c6f20776f726c6421 READY: loaded 14 instructions -NEO-GO-VM 0 > run +TUTUS-VM 0 > run [ { "type": "ByteString", @@ -149,7 +149,7 @@ automatically (please refer to the `run` command help), but if you need to pass a parameter of a specific type you can specify it in `run`'s arguments: ``` -NEO-GO-VM > run rollDice int:1 +TUTUS-VM > run rollDice int:1 ``` > The method is always of type string, hence we don't need to specify the type. @@ -157,7 +157,7 @@ NEO-GO-VM > run rollDice int:1 To add more than 1 argument: ``` -NEO-GO-VM > run someMethod int:1 int:2 string:foo string:bar +TUTUS-VM > run someMethod int:1 int:2 string:foo string:bar ``` Currently supported types: @@ -166,24 +166,24 @@ Currently supported types: - `string (string:foo string:this is a string)` ## Debugging -The `neo-go-vm` provides a debugger to inspect your program in-depth. +The `tutus-vm` provides a debugger to inspect your program in-depth. ### Stepping through the program Step 4 instructions. ``` -NEO-GO-VM > step 4 +TUTUS-VM > step 4 at breakpoint 3 (DUPFROMALTSTACK) -NEO-GO-VM 3 > +TUTUS-VM 3 > ``` Using just `step` will execute 1 instruction at a time. ``` -NEO-GO-VM 3 > step +TUTUS-VM 3 > step at breakpoint 4 (PUSH0) -NEO-GO-VM 4 > +TUTUS-VM 4 > ``` ### Breakpoints @@ -191,11 +191,11 @@ NEO-GO-VM 4 > To place breakpoints: ``` -NEO-GO-VM > break 10 +TUTUS-VM > break 10 breakpoint added at instruction 10 -NEO-GO-VM > cont +TUTUS-VM > cont at breakpoint 10 (SETITEM) -NEO-GO-VM 10 > cont +TUTUS-VM 10 > cont ``` ## Inspecting stack @@ -203,7 +203,7 @@ NEO-GO-VM 10 > cont Inspecting the evaluation stack: ``` -NEO-GO-VM > estack +TUTUS-VM > estack [ { "value": [ diff --git a/examples/README.md b/examples/README.md index f0608bd..5ee4005 100644 --- a/examples/README.md +++ b/examples/README.md @@ -1,4 +1,4 @@ -# NeoGo smart contract examples +# Tutus smart contract examples `examples` directory contains smart contract examples written in Go. These examples are aimed to demonstrate the basic usage of Go programming @@ -34,26 +34,26 @@ See the table below for the detailed examples description. | [storage](storage) | The contract implements API for basic operations with a contract storage. It shows how to use `storage` interop package. See the `storage` [package documentation](../pkg/interop/storage/storage.go). | | [timer](timer) | The idea of the contract is to count `tick` method invocations and destroy itself after the third invocation. It shows how to use `contract.Call` interop function to call, update (migrate) and destroy the contract. Please, refer to the `contract.Call` [function documentation](../pkg/interop/contract/contract.go) | | [token](token) | This contract implements NEP-17 token standard (like NEO and GAS tokens) with all required methods and operations. See the NEP-17 token standard [specification](https://github.com/neo-project/proposals/pull/126) for details. | -| [zkp/cubic_circuit](zkp/cubic_circuit) | This example demonstrates how to create your own circuit and generate Groth-16 proof based on BLS12-381 elliptic curve points with the help of [consensys/gnark](https://pkg.go.dev/github.com/consensys/gnark). It also shows how to generate, deploy and invoke Verifier smart contract to verify proofs for the given circuit on the Neo chain with the help of [zkpbindings](https://pkg.go.dev/github.com/tutus-one/tutus-chain/pkg/smartcontract/zkpbinding) NeoGo package. The package also contains circuit tests implemented with [gnark/test](https://pkg.go.dev/github.com/consensys/gnark/test) to check the circuit validity and end-to-end proof generation/verification test implemented with [neotest](https://pkg.go.dev/github.com/tutus-one/tutus-chain/pkg/neotest) to demonstrate how to build, deploy and verify proofs via Verifier smart contract for the given circuit. | +| [zkp/cubic_circuit](zkp/cubic_circuit) | This example demonstrates how to create your own circuit and generate Groth-16 proof based on BLS12-381 elliptic curve points with the help of [consensys/gnark](https://pkg.go.dev/github.com/consensys/gnark). It also shows how to generate, deploy and invoke Verifier smart contract to verify proofs for the given circuit on the Neo chain with the help of [zkpbindings](https://pkg.go.dev/github.com/tutus-one/tutus-chain/pkg/smartcontract/zkpbinding) Tutus package. The package also contains circuit tests implemented with [gnark/test](https://pkg.go.dev/github.com/consensys/gnark/test) to check the circuit validity and end-to-end proof generation/verification test implemented with [neotest](https://pkg.go.dev/github.com/tutus-one/tutus-chain/pkg/neotest) to demonstrate how to build, deploy and verify proofs via Verifier smart contract for the given circuit. | ## Compile -Please, refer to the neo-go +Please, refer to the tutus [smart contract compiler documentation](../docs/compiler.md) to compile example smart contracts. ## Deploy -You can set up neo-go private network to deploy the example contracts. Please, +You can set up tutus private network to deploy the example contracts. Please, refer to the [consensus documentation](../docs/consensus.md) to start your own -privnet with neo-go nodes. +privnet with tutus nodes. To deploy smart contracts, refer to the [Deploying section](../docs/compiler.md#deploying) of the compiler documentation. ## Where to start -Feel free to explore neo-go smart contract development +Feel free to explore tutus smart contract development [workshop](https://github.com/tutus-one/tutus-chain-sc-wrkshp) to get the basic concepts of how to develop, compile, debug and deploy Neo smart contracts written in go. diff --git a/examples/zkp/cubic_circuit/README.md b/examples/zkp/cubic_circuit/README.md index 7241bda..9a81e0d 100644 --- a/examples/zkp/cubic_circuit/README.md +++ b/examples/zkp/cubic_circuit/README.md @@ -4,7 +4,7 @@ proof based on BLS12-381 elliptic curve points with the help of [consensys/gnark](https://pkg.go.dev/github.com/consensys/gnark). It also shows how to generate, deploy and invoke Verifier smart contract to verify proofs for the given circuit on the Neo chain with the - help of [zkpbindings](https://pkg.go.dev/github.com/tutus-one/tutus-chain/pkg/smartcontract/zkpbinding) NeoGo package. The package also contains circuit + help of [zkpbindings](https://pkg.go.dev/github.com/tutus-one/tutus-chain/pkg/smartcontract/zkpbinding) Tutus package. The package also contains circuit tests implemented with [gnark/test](https://pkg.go.dev/github.com/consensys/gnark/test) to check the circuit validity and end-to-end proof generation/verification test implemented with [neotest](https://pkg.go.dev/github.com/tutus-one/tutus-chain/pkg/neotest) to demonstrate how to build, deploy and verify proofs via Verifier smart @@ -58,6 +58,6 @@ Take the [`TestCubicCircuit_EndToEnd_Prod`](./main_test.go) test logic as a basi while generating the circuit-specific proving and verifying keys for the production usage. Currently, we don't have a BLS12-381 specific Groth-16 setup CLI utility like for [BN254 curve](https://github.com/bnb-chain/zkbnb-setup), but eventually -it will be included into the NeoGo toolkit to make the development process easier. +it will be included into the Tutus toolkit to make the development process easier. Don't hesitate to contact us if you're looking for a similar CLI utility for BLS12-381 curve. \ No newline at end of file