tutus-one
/
tutus-chain
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update documentation for Tutus branding and professional README 

- Rewrite README with professional presentation
  - Add MarketAlly as developer organization
  - Add David H. Friedel Jr. as Lead Architect
  - Comprehensive native contracts documentation
  - Architecture diagram and security features
  - Acknowledge Neo foundation in Acknowledgments section

- Remove upstream references from all documentation
  - docs/*.md updated for Tutus branding
  - CHANGELOG.md, ROADMAP.md updated
  - examples/ documentation updated
  - VM prompt changed to TUTUS-VM
This commit is contained in:
Tutus Development 2025-12-21 05:07:54 -05:00
parent 4b740b45cf
commit 1ff1bcf982
16 changed files with 427 additions and 323 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

126
CHANGELOG.md
View File

@ -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

240
README.md
View File

@ -1,88 +1,192 @@
# Tutus Chain
<p align="center">
<h1 align="center">Tutus</h1>
<p align="center">
<strong>Sovereign Blockchain Infrastructure for Government</strong>
</p>
<p align="center">
<a href="https://tutus.one">Website</a> |
<a href="#quick-start">Quick Start</a> |
<a href="#documentation">Documentation</a> |
<a href="#license">License</a>
</p>
</p>
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.
```
---
<p align="center">
<sub>Built with purpose for humanity's digital future</sub>
</p>

4
ROADMAP.md
View File

@ -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.

104
docs/cli.md
View File

@ -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

48
docs/compiler.md
View File

@ -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 <sender> --wallet /path/to/wallet.json --account <account>
./bin/tutus contract manifest add-group -n contract.nef -m contract.manifest.json --sender <sender> --wallet /path/to/wallet.json --account <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

38
docs/consensus.md
View File

@ -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 <dir-from-step-2>`.
3. Start all nodes with `tutus node --config-path <dir-from-step-2>`.

10
docs/neofs-blockstorage.md
View File

@ -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.

20
docs/node-configuration.md
View File

@ -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 <br> https://github.com/neo-project/neo/pull/2712 <br> https://github.com/tutus-one/tutus-chain/pull/2519 <br> https://github.com/neo-project/neo/pull/2749 <br> 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 <br> https://github.com/neo-project/neo/pull/2712 <br> https://github.com/tutus-one/tutus-chain/pull/2519 <br> https://github.com/neo-project/neo/pull/2749 <br> 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 <br> https://github.com/neo-project/neo/pull/2881 <br> https://github.com/tutus-one/tutus-chain/pull/3080 <br> https://github.com/neo-project/neo/pull/2883 <br> https://github.com/tutus-one/tutus-chain/pull/3085 <br> 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 <br> https://github.com/neo-project/neo/pull/2942 <br> https://github.com/tutus-one/tutus-chain/pull/3301 <br> https://github.com/neo-project/neo/pull/2925 <br> https://github.com/tutus-one/tutus-chain/pull/3362 <br> 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 <br> https://github.com/neo-project/neo/pull/3290 <br> https://github.com/tutus-one/tutus-chain/pull/3473 <br> https://github.com/neo-project/neo/pull/3290 <br> https://github.com/neo-project/neo/pull/3301 <br> 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 <br> https://github.com/neo-project/neo/pull/3290 <br> https://github.com/tutus-one/tutus-chain/pull/3473 <br> https://github.com/neo-project/neo/pull/3290 <br> https://github.com/neo-project/neo/pull/3301 <br> 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 <br> https://github.com/tutus-one/tutus-chain/pull/3761 <br> https://github.com/tutus-one/tutus-chain/pull/3554 <br> https://github.com/neo-project/neo/pull/3597 <br> https://github.com/tutus-one/tutus-chain/pull/3700 <br> https://github.com/tutus-one/tutus-chain/pull/3640 <br> https://github.com/neo-project/neo/pull/3548 <br> https://github.com/tutus-one/tutus-chain/pull/3863 <br> https://github.com/neo-project/neo/pull/3696 <br> https://github.com/neo-project/neo/pull/3895 <br> https://github.com/tutus-one/tutus-chain/pull/3835 <br> https://github.com/tutus-one/tutus-chain/pull/3854 <br> https://github.com/neo-project/neo/pull/3175 <br> https://github.com/tutus-one/tutus-chain/pull/3478 <br> 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 <br> https://github.com/tutus-one/tutus-chain/pull/4004 <br> https://github.com/neo-project/neo/pull/4147 <br> https://github.com/neo-project/neo/pull/4150 <br> https://github.com/tutus-one/tutus-chain/pull/4057 <br> https://github.com/neo-project/neo/pull/4278 <br> https://github.com/tutus-one/tutus-chain/pull/4052 <br> 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`,

28
docs/notary.md
View File

@ -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

4
docs/oracle.md
View File

@ -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).

8
docs/release-instruction.md
View File

@ -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.

52
docs/rpc.md
View File

@ -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

8
docs/stateroots.md
View File

@ -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.

44
docs/vm.md
View File

@ -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 [<n>]
<n> is optional parameter to specify number of instructions to run, example:
@ -79,14 +79,14 @@ Usage: step [<n>]
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": [

12
examples/README.md
View File

@ -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.

4
examples/zkp/cubic_circuit/README.md
View File

@ -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.