-
D B authored7c9de513
- Adi Release
- Prerequisites:
- Docker - Docker daemon (dockerd) and Docker CLI (docker)
- Installation
- Docker Confguration
- Libp2p Gossip Bootstrap Configuration
- Node Configuration
- Sagachain Configuration
- Sagachain Launching
- Sagascan-UI
- SagaScan-UI
- Sagascan Server Configuration
- SagaScan-Server
- Example Test Transactions
- Setup
- Configuring the Libp2p Gossip Bootstrap peers
- Output:
- Configuring the bootstrap peers in the sagachainnodeXX.yaml files
- Sending the configuration to the rest of the machines:
- Configuring the docker run script
- Docker Swarm and Overlay Configuration
- Launching the Blockchain
- Sagachain Blockchain Explorer and Submitting Transactions
- Sagascan-UI
- Transaction Usage
- Transaction Tools
- spclient
- saga-outside-client
- Test Transaction Scripts
- Classassetexample.py
- newaccountexample.py
- newaccountaddasset.py
- newaccountincrementasset.py
- Test Scaffolding
- scriptloadassetclass.sh
- scriptincrementclassassetsh
- New Account and Object Creation and Use
- Disclaimers
- What's next
Adi Release
February 22, 2025 Prasaga
Our first release, the Adi release, is an individual private test development sharded static blockchain to introduce the Sagachain concepts and allow some preliminary experimentation with these concepts in a limited, but live example system. Specifically, Sagachain nodes are instances of a docker image and communicate using a docker swarm overlay network. Nodes also communicate using the libp2p gossipsub package and libp2p rendezvous instances. A webserver instance and mongodb database provide a blockchain explorer to monitor block production and transactions of the running nodes. A configured system enables developers to run a multi-sharded blockchain, create new account objects, new class objects, new object instances, send transactions involving arbitrary sets of accounts, and monitor results with the block explorer.
Prerequisites:
Sagachain is built for Linux x86_64 architectures. Development and testing is generally carried out on Amazon Linux 2023 on EC2 instances. This release is in a Docker image minimizing system dependencies as much as possible. Configuration files require some manual editing, and a couple system specific utility replacements. The following are the minimal tools that must be installed:
Docker - Docker daemon (dockerd) and Docker CLI (docker)
Note: The Docker ports needed for the Docker swarm overlay bridge must be open between machines:
-
TCP port 2377
-
TCP and UDP port 7946
-
UDP port 4789 reference: Networking with overlay networks | Docker Docs)
-
Npm and node.js - reference: https://docs.npmjs.com/downloading-and-installing-node-js-and-npm
-
Mongodb - reference: https://www.mongodb.com/docs/manual/administration/install-on-linux/?msockid=04790d77b32a6db30fda18f6b2766c13
-
ssh (ssh, sshd, scp)
-
standard Linux utilities
Installation
The Sagachain Node is hosted at Repositories | sagachain, sagachain/node:v1.0.0. Configuration and runtime scripts are hosted at SagaChain / configs · GitLab. This short setup script will clone the configuration, databases, and block explorer related projects.
#!/bin/bash
echo "***Adi release for developers***"
git clone --branch v3.1.1 --depth 1 --single-branch https://code.prasaga.com/sagachain/configs.git
git clone --branch v3.1.1 --depth 1 --single-branch https://code.prasaga.com/sagachain/databases.git
git clone --branch v3.1.1 --depth 1 --single-branch https://code.prasaga.com/sagachain/sagascan-ui.git
git clone --branch v3.1.1 --depth 1 --single-branch https://code.prasaga.com/sagachain/sagascan-server.git
git clone --branch v3.1.1 --depth 1 --single-branch https://code.prasaga.com/sagachain/saga-bootstrap-node.git
To call: curl https://code.prasaga.com/sagachain/configs/-/raw/main/sagachain-bootstrap.sh | bash -s
Docker Confguration
The Node containers use the docker overlay network for the consensus protocol, and host IP visible libp2p gossip rendezvous instances for the libp2p gossipsub module. Docker swarm and overlay network configuration documentation can be found on the docker website tutorial section. If all of the Node docker containers are run on the same machine, the default docker bridge without the overlay bridge configuration may be used.
Libp2p Gossip Bootstrap Configuration
The Node gossipsub module uses a bootstrap rendezvous instance for peer discovery. At least one rendezvous instance must be available via a host IP visible address. The tool saga-bootstrap-node/bootstrap-node implements a basic rendezvous instance. It outputs a bootstrap peer libp2p multiaddress template that is used added to each Node configuration file. Saga-bootstrap-node/bootstrap-node supports peer rendezvous instances which can be passed as a command line argument with the -peers switch. See the source code for details saga-bootstrap-node/main.go. The bootstrap peers configuration is described in the setup section below.
Node Configuration
Each Node takes a commandline parameter “--config=<path>/<name>.yaml file. And a logfile configuration which defaults to noderlog.conf or an be set with the environment variable: NODE_CONF_FILE. The Node configuration file and required configurations is described in the setup section below.
Sagachain Configuration
The set of shards, Nodes assigned to each shard, and operating modes of each Node are defined in a configuration file: saganodelist.yaml. Each Node configuration file described above includes a reference to this configuration file with the tag “nodelistpathname:”.
The Sagachain configuration file and required configurations are described in the setup section below.
Sagachain Launching
A series of rudimentary bash scripts are provided for setting up and launching a set of configured Node to run as a Sagachain multi-shard blockchain. Unlike adding a new Node instance to a running blockchain, the development scripts launch all of the Nodes as a complete set using the following scripts:
- Make_sagachain_config.sh
- Docker-sagachain-node.sh
- Sagachain-manager.sh
- Runnode_sagachain.sh
The configuration and usage is described in the setup section below.
Sagascan-UI
Details on configuration and launching the sagascan UI can be found in the readme at: https://code.prasaga.com/sagachain/sagascan-ui The Sagacan-UI and Sagascan-Server can be built and run with a Docker compose file.
The readme can be found in the sagascan-ui project, and reproduced here:
SagaScan-UI
SagaScan-UI
SagaChain viewer, offers a streaming display of latest blocks and transactions.
Block detail view with included transactions,
transaction details including executed script and results.
Blocks and transactions can be searched by hash.
Display overall statics and charts with blocks/s and transactions/s
Connects to the SagaScan-server web and websocket api.
In the future it will be expanded to display and modify accounts
and individual objects, submit transaction scripts and display node information
as well as additional statistics.
Run with Docker
To run the SagaScan-UI with Docker, please pull both this repo and sagascan-server
next to each other in the same directory.
Adjust the environment variables in the docker-compose.yml file to match your setup, especially the SAGA_NODE
which should point to the SagaChain node you want to connect to and the VITE_API variable to point to your SagaScan-server instance.
It will then be available on port 3000, e.g. http://localhost:3000 with the sagascan-server being called on http://localhost:3001 .
docker compose build
docker compose up
Installation
Alternatively you can run the SagaScan-UI directly on your server using the following commands.
Copy the default.env file to .env and adjust the VITE_API variable to point to your SagaScan-server instance.
npm install
npm run build
pm2 start .output/server/index.mjs
uses port 3000
Copy .env.default to .env and adjust VITE_API for the SagaScan-server URL
Example nginx config section for reverse proxy
location / {
proxy_pass http://localhost:3000;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
location /_nuxt {
root /home/ec2-user/sagascan-ui/.output/public/;
}
location /api {
rewrite ^/api(.*)$ $1 break;
proxy_pass http://localhost:3001;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
location /api/ws {
rewrite ^/api(.*)$ $1 break;
proxy_pass http://localhost:3001;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
Sagascan Server Configuration
Details on configuration and launching the sagascan server can be found in the readme at: https://code.prasaga.com/sagachain/sagascan-server If using the Docker compose from the sagascan-ui, the following is not needed. Readme reproduced here:
SagaScan-Server
Web and websocket api server for the SagaScan-UI and as basis for external projects to access SagaChain. Streams recent blocks and contained transactions via websocket by connecting to a SagaChain Node via GRPC. Also stores the data in a mongoDb database for indexing and later retrieval via hash or block id.
In the future additional elements will be made available, e.g. nodes, accounts, objects, as well as the ability to filter by account, etc. Also the ability to submit transactions will be added.
API documentation to follow. Client library reference implementations will be provided.
The .proto files are copied from the repo saga-pbtypes.
Environment variables (.env file)
SAGA_NODE defaults to localhost:5080
Uses mongodb with DB_URL defaulting to mongodb://localhost:27017/sagachain. Set USE_DB=0 to disable mongodb, useful for debugging. While debugging nodes to handle block resets set DETECT_RESTARTS=1
To init the db see mongo.txt , to reset db use mongosh \< resetDb.js
For example nginx setup see the frontend repo sagascan-ui.
npm install
npm run dev
Example Test Transactions
A minimal set of two test scripts exercise the blockchain as follows: A transaction that creates a new Sagapython class implementing a simple counting asset and owned by the built-in SystemAccount object, and creates a new instance of the class which is also owned by SystemAccount. A transaction that sends a message to the new object instance increment the asset count. This transaction is submitted repeatedly by a shell script, increment the transaction sequence number for each submission.
A set of three transactions the can be used to create new accounts, create new object instances owned by the new accounts (currently uses the class previously created above), and sends messages to the object instances owned by the accounts. Some manual editing is required to capture the newly created the object IDs (32 byte hash values), for the new accounts and objects.
The transactions configuration and usage are described after setup section below.
Setup
Once the download script is run, the following directories will have been cloned: Configs and databases. The make_sagachain_config.sh creates a working copy of the configs and databases directory with a name for the new blockchain. It takes 3 parameters:
- Path to the parent directory of the configs and databases directories from the install script.
- Name of the blockchain to create – creates a directory by that name in the current working dir
- Number of nodes for the blockchain. See blockchain configuration and Node configuration below. The default is 16, 4 nodes per shard and 4 shards.
configs/make_sagachain_config.sh <install root>/ <blockchain> 16
On completion, the <blockchain> directory containing a configs directory and a databases directory should exist.
Configuring the Libp2p Gossip Bootstrap peers
The Nodes connect to one or more libp2p rendezvous bootstrap hosts to discover each other for gossip traffic. The saga-bootstrap-node directory contains bootstrap-node. The command will run a libp2p rendezvous process and output a unique key. The unique key is written to a file .priv in the current working directory.
saga-bootstrap-node/bootstrap-node
Output:
[*] Your Bootstrap ID Is: /ip4/0.0.0.0/tcp/5000/p2p/QmPA5aeSDNaryS3b8dCXFdVY3MmoaTfqv16dsHRfYYazCh
Of which, the key is:
QmPA5aeSDNaryS3b8dCXFdVY3MmoaTfqv16dsHRfYYazCh
The command may be run detached in the background:
Nohup saga-bootstrap-node/bootstrap-node &
And the nohup.out will contain the output.
The saga-bootstrap-node/bootstrap-node takes a -peers flag which is a list of other bootstrap nodes such that several may refer to each other.
Configuring the bootstrap peers in the sagachainnodeXX.yaml files
In the <blockchain name>/configs directory edit sagachainnode1.yaml.
Search for the bootstrap_peers: entry list. There are several peers already listed. These can be deleted. Use the entries as a template, replacing the IP address with the host IP address and the key with the generated key from above.
Any number of bootstrap_peers may be listed, at least one must be listed and available for the nodes to connect to.
SagachainnodeXX.yaml replication script
To avoid manual editing each sagachainnodeXX.yaml file a short script will duplicate sagachainnode1.yaml, editing the node name in the configuration file, node2, node3, …
It does a couple simple sed edits.
Run this in the <blockchain name>/configs directory:
pushd <blockchainname>/configs; gen-chainnode-configs.sh 17; popd
This will recreate sagachainnode2.yaml, … sagachainnode16.yaml from the sagachainnode1.yaml edited version.
Sending the configuration to the rest of the machines:
Each machine needs a copy of the configuration files in a <blockchain name>/configs directory and a copy of the databases in <blockchain name>/databases. A minimal script is provided to do start, stop, copying commands, sagachain-manager.sh. This depends on ssh/sshd being configured correctly. It expects to find the keys in ~/.ssh as ${hostname}.pem files. The make_sagachain_config.sh makes a copy of the ./etc directory with 2 files: hosts and nodes. Example hosts file:
ec2-user@50.18.65.58 Node1
#ec2-user@54.215.87.20 Node2
ec2-user@54.176.27.64 Node3
ec2-user@3.101.67.251 Node4
localhost Node2
ec2-user@3.101.86.194 Node5
The first entry is the username and host for each machine that will run one or more Nodes. The second is the prefix name for the .pem files in .ssh, (e.g. ~/.ssh/Node1.pem)
The etc/nodes file lists the location of each Node instance by hostname and number. Example nodes file:
Node1
Node2 1 2 3 5 6
Node3
Node4 9 10 11 13 14 15
Node5 4 7 8 12 16
This means Node2 will run Nodes with configuration files sagachainnode1.yaml, sagachainnode2.yaml, etc. and Node4 and Node5 will run Nodes with the respective sagachainnodeXX.yaml config files.
Configuring the docker run script
The docker-sagachain-node.sh edits the sagachainnodeXX.yaml files to use the host machine IP address for each Node instance. Development has been hosted on AWS EC2 machines, such that the default uses the ec2-metadata command. The lines edit are near the top of the file, reproduced here:
# command to retrieve the hosts externally visible IP address
# if using AWS ec2, following command works. Replace for other platforms
export EXT=$(ec2-metadata -v --quiet)":$p4"
export LOC=$(ec2-metadata -R --quiet)
echo "- $EXT $LOC"
It is recommended to not hardcode these, use an appropriate host command to retrieve the host IP address on each run. This makes it easier to move Nodes around using the sagachain-manager.sh script described below. Deploying the configs and databases After completing configuring the hosts and nodes files, and editing the docker-sagachain-node.sh file, the sagachain-manager.sh may be used to copy the directories to the target machines using scp:
configs/sagachain-manager.sh <blockchain name> scp -r <blockchain name> <blockchain name>
The first parameter to sagachain-manager.sh is always the blockchain name. The second is one of start, stop, start-debug, scp, and several others. Please refer to the case statement in the bash script for the commands. The scp utility takes two directories, the source and destination. In this case it copies the configuration directories from the source machine to all of the target machines.
Docker Swarm and Overlay Configuration
For details on docker configuration please refer to the online docker network tutorial. The relevant commands are:
docker swarm init
To create a network with this machine as the designated network manager. It returns a network token that is used for joining the other host machines.
docker swarm join --token <returned token> <manager IP address>:2377
On each of the other host machines. Note: there is a general “cmd” command for sagachain-manager.sh available:
configs/sagachain-manager.sh <blockchain name> cmd docker swarm join –token <…> <ip address>:2377
Launching the Blockchain
The sagachain-manager.sh will start the blockchain by downloading the sagachain Node image from hub.docker.com and execute each of the instances on the configured host machines with the appropriate sagachainnodeXX.yaml configuration file. As part of the initial launch sagachain-manager creates a temporary directory: saganodetmp-<blockchainname> and makes a copy of the configuration files and the sagachainnodeXX.yaml files used on each host machine.
configs/sagachain-manager.sh <blockchain name> start sagachain/node:v1.0.0
The start command takes 4 additional parameters with are TCP port numbers. The docker bridge configuration uses port numbers to distinguish between instances. The port numbers used for each instance are output as part of the start command.
The start command copies the configuration from the <blockchain name> directories to the saganodetmp-<blockchain-name> directories for each run. A separate command, start-debug will reuse the configuration files in the saganodetmp-<blockchain-name>. This is useful for enabling various log tracing parameters for a Node instance.
Note: the source code is heavily instrumented with log statements. The bottom section of the sagachainnodeXX.yaml files have examples of trace flags that may be enabled. The noderlog.conf file in the configs directory controls the overall logging using the Go rlog package. To enable trace logging:
RLOG_TRACE_LEVEL = 1000 or higher value.
To verify the Nodes are up:
docker ps
Should show the list of nodes for the machine that you have configured the etc/nodes for.
docker logs -f <blockchain name>-nodeX X
To see the log of the main node process for the container. Each container will have the following:
- node process – implements consensus, and manages everything
- saga-leveldb process – implements the object state database
- executor processes – farm of sagapython processes to execute transactions
- extractheader processes – farm of sagapython process for initial header reads on transaction submission.
Sagachain Blockchain Explorer and Submitting Transactions
The sagachain blockchain explorer is found in the directories sagascan-server and sagascan-ui. Each has a readme for launching. To run:
- copy the .env.default to .env and edit if needed.
- execute mongodb instance with the commands in mongo.txt found in sagascan-server
- execute the server:
npm install ; npm run dev; npm run pm2
The server connects to a Node instance, which is usually co-resident on the same host machine. If not the .env should edited appropriately.
Sagascan-UI
Change to the sagascan-ui directory. Copy the .env.default to .env. Edit the VITE_API if the sagascan-server instance is on a different machine. Execute the UI:
npm install ; npm run dev; npm run pm2
Transaction Usage
The following walkthroughs demonstrate the following:
- Creating a new class object on Sagachain
- Creating an instance of the new class, owned by the built-in SystemAccount
- Sending messages to the new instance to increment a stored field value
- Creating a new account object
- Creating a new object of the class previously created, owned by the new account object
- Sending messages to the object owned by the new account to increment a stored field value.
The example transaction scripts may be found in configs/testscripts. The best way to run the transactions is from within a Node container. A separate container may be launched or one can connect to one of the existing Node containers:
docker exec -it <blockchain name>-nodeXX /bin/bash
Change to the testscripts directory and run the setup. The setup updates the path for sagapython:
cd /opt/testscript . setup.sh
Transaction Tools
spclient
spclient is part of the sagapython package and is used for signing transactions with a private key. To "bootstrap", there is a wellknown key for the built-in SystemAccount object: systemccount.signing.key spclient --help returns the available command line options:
__main__.py - usage:
--help display this help message
--first-operand <filename of transaction script> is required, plus optional switches
-o ARG --outfile ARG processes transaction script output file
-s ARG --sig ARG signing key
-p ARG --SPIMPORTPATH ARG Set import path for sagapython doimport(). default uses environment variable by same name
General usage is:
spclient <transaction script>.py -o <signed output filename> -s <signing key>
In addition to signing the transaction, spclient performs a user-side source import capability with the builtin function doimport() and CMIImport(). The transaction scripts have examples of these. Together they function similar to an import or include directive in most programming languages. CMIImport() has additional capabilities for importing from objects in the blockchain database. This feature is not used for the current example transaction scripts. The Sagpython Users Guide describes the concepts and syntax of Sagapython (An updated release of the guide will be out shortly. Some syntax has changed regarding object account ownership)
saga-outside-client
saga-outside-client may be found in the testscript directory. The source may be found at https://code.prasaga.com/sagachain/sagachain-client:
./saga-outside-client --help returns:
Usage of ./saga-outside-client:
-address string
domain or ip with port of server listener. eg:127.0.0.1:50051
-file string
file path
saga-outside-client submits a transaction to a single node using gRPC and a protobuf message. The output of spclient is sent as the transaction text. An immediate return of SUCCESS indicates that the node accepted the transaction to is memqueue but it does not mean it executed it. Other returns are BUSY, which means the Node event input queue is temporarily full, and ERROR, which is returned if the signature check fails, or a preliminary reading of the transaction header fails.
saga-outside-client does not return the result of the transaction or notify if the transaction as been added to a block and reached consensus. (Note: future development will add this and/or support existing client platforms e.g. metamask) The current means to recognize a transaction has executed and reached consensus is to observe the sagascan-ui for the transaction.
Test Transaction Scripts
Classassetexample.py
classassetexample.py creates a new class object that implements a simple counter field with a couple of methods. By default class objects are owned by the SystemAccount account object, but may be owned by any ClassAccount object instance.
newaccountexample.py
newaccountexample.py creates a new account with an arbitrary initialization of coin. Note that Sagacoin is not supported in the developer release. Account creation is just for exercising the shard scaling and experimentation purposes.
newaccountaddasset.py
newaccountaddasset.py creates a new instance of the ClassAsset using the ClassAsset ObjectID created by the first transaction above. The new object is assigned ownership to the new account. The asset is given a string name "Champion Sparkplugs".
newaccountincrementasset.py
newaccountincrementasset.py sends a message to the new asset instance increment the current value it is storing.
Test Scaffolding
Two scripts, scriptloadassetclass.sh and scriptincrementassetclass.sh use bash here documents (<<-) to edit the respective sagapython transaction scripts, and to sign and submit them.
scriptloadassetclass.sh
scriptloadssetclass.sh has a here document of the classassetexample.py which is signs and submits to a node. It takes one parameter, the name of the node and port number. The client port number for each node is configured to be 5051, and may be changed in each sagachainnodeXX.yaml file. Calling the script:
. testscript/scriptloadassetclass.sh <blochcain name>-node1:5051
(all of the nodes are listening on port 5051)
When the transaction reaches consensus, it's hash will be lists in the Latest Transactions window of the sagascan block explorer. Clicking on that will bring up a window that includes the transaction script and the text result output. The new class LOID (Ledger Object ID) and a new instance LOID of the new class are the return text of the transaction __body() function.
scriptincrementclassassetsh
scriptincrementclassasset.sh sends transaction that contains a message to increment the asset value in the Class Asset object in a loop on a timed basis. It takes two parameters: the node address as above, and a starting sequence number for the transactions. It continues in an infinite loop until aborted.
. testscript/scriptincrementclassasset.sh <blochcain name>-node1:5051 <integer>
The sagascan block explorer will show the list of transactions as they are included in consensus blocks. An account object's state may only be modified in a transaction on one shard at any given time. This is managed through Sagachain's concept of account ownership by shards. The these two test scripts are sending messages to a single object owned by a single account, SystemAccount. The SystemAccount can only be owned by one shard at a time. The account negotiation protocol assigns the SystemAccount to different shards over time using a weighted, randomized search algorithm. The transactions will execute on diferent shards over time which proves the account ownership protocol.
New Account and Object Creation and Use
To use the newaccountexample.py to create a new account. It uses a previously generated private/public key pair. The public key is assigned to a variable in the __body() function and is passed to the new account object as an initialization parameter. The private key is in the testscript/newaccount.signing.key. The transaction is sent to the SystemAccount to create the account. It is signed with the SystemAccount key.
spclient newaccountexample.py -o newaccountexample.sgn -s systemacccount.signing.key
the output transaction is ready to be submitted to the blockchain:
./saga-outside-client -address <blockchain name>-node1 -file newaccountexample.sgn
Once submitted watch the sagascan to see the transaction reach consensus. Once completed open the transaction in sagascan. The output string will be newacct = "....." Where the string is the 32byte LOID for the new account in hex ascii. The next script, newaccountaddasset.py uses an import file to read in the new LOID. The import file is named newaccountloid.py. It contains a single line:
NewAccountLOID = '35c565b7ec8dfc909e249669ac9624bd1a669d1166f786e50000000000000000'
replace the LOID with the output from the previous transaction. This file is imported into the newaccountaddasset.py transaction with the doimport() function. Refer to the transaction text for the implementation.
The newaccountasset.py creates a new instance of ClassAsste. It must be signed with the newaccount.signing.key and submitted:
splclient newaccountasset.py -o newaccountasset.sgn -s newaccount.signing.key ./saga-outside-client -address <blockchain name>-node1 -file newaccountasset.sgn
Find the transaction in the sagascan explorer. Its output string is newasset="...". The LOID for the new ClassAsset object instance that was instantiated and added to the new account. The file theassetloid.py is imported by the transaction script newaccountincrementasset.py. It contains a single line:
theassetLOID = '35c565b7ec8dfc909e249669ac9624bd1a669d1166f786e50000000200010000'
where the LOID must be replaced with the output string in newasset="...".
The newaccountincrementasset.py may now be edited, signed and submitted. Each transaction includes a header that contains among other parameters a sequence number. The sequence number prevents transaction replay attacks. Each account has a unique sequence number. It is a 32bit value thus supporting up to 4 billion transactions over the life of a single account. It is only necessary that the sequence number continues to grow, but is expected to usually be incremented by 1 for each transaction submitted. The steps are:
- Open the transaction in an editor and update the sequence Number
- Sign as above, with the newaccount.signing.key
- Submit as above.
The header fields are reproduced here:
def __hdr():
newacct = doimport('newaccountloid.py')
CMIImport('newacct', 'newacct', '*')
hdr = { 'accts': NewAccountLOID,
'seq': 1000, # whatever the next sequence number is
'maxGU': 10,
'feePerGU': 1,
'extraPerGU': 2,
'primaryAccount': NewAccountLOID,
'nonce': 0,
}
return hdr
The sequence number field is 'seq'. After editing, sign and submit:
splclient newaccountincrementasset.py -o newaccountincrementasset.sgn -s newaccount.signing.key ./saga-outside-client -address <blockchain name>-node1 -file newaccountincrementasset.sgn
The output string from the transaction is:
Increment Count after: <asset count>
The transaction may be updated, signed and submitted repeatedly. It may also be uses in a bash here document as with the test transactions. The sequence of creating a new account, new asset object and incrementing may be repeated to test multiple accounts executing across the shards.
The current test transactions only involve a single account (technically the new account transaction also involves the class Asset object owned by the SystemAccount), but the transactions are not limited to sending messages to a single object in a single account. A transaction can send message to any number of objects in any number of accounts. A method implementation for a class may send additional messages to any number of objects, and so on. Sagachain's job is to identify the accounts involved in each transaction and arrange that when the transaction is executed on a shard, all the accounts' state are current, and only one shard executes the transaction and modifies the accounts and objects states.
Disclaimers
Disclaimers: This release is a work in progress. It is a functioning blockchain, but it is not a crypto blockchain and is not secured by block signature authentication. Although the capability exists to implement transaction fees, generate coin, and general coin management, that is not the focus of this release and is not used as part of the transaction examples.
The blockchain uses 3 consensus algorithms: Signature BFT in a P2P mode, POW in a P2P mode, and Signature BFT in a point-multipoint model using a version of the Hotstuff protocol. The developer release is intended for experimentation and development
with SagaPython. Although Sagachain is a consensus based blockchain, this release does not implement liveliness protocols. As such it will stall for a variety of reasons that will be recoverable in the future. Sagachain is intended
to use the multiple shards as a means to provide liveliness. Individual shards do not provide liveliness, but the Sagachain protocol, when complete, will not stall due to the loss of a shard. This is not the case for the developer release. A variety
of situations will stall the chain.
The Sagachain database has a single genesis block on shard0 database. There are 9 other shard databases shipped with the release. The developer release uses a configuration file to define the shards and nodes statically at boot time. Dynamic shard creation and termination is in the design plan, but has not been implemented for this release.
Sagachain does not currently support adding nodes to a running chain and downloading the existing shard databases and shard chains. Therefore no state is carried over between runs of the blockchain using the existing scripts. It may be possible to restart a blockchain with an existing set of shard databases. The sagachain-manager.sh script overwrites the databases on each start up with the default empty databases. Future releases will include bring up of new nodes with state download.
Finally, the source code is sprinkled with many asserts, Go panics and python exceptions intentionally to help with development and debugging. Many of these occur for reasons such as transaction execution errors and block validation failures based on the assumption that there currently are no "rogue" nodes on the chain purposefully sending corrupt data. Thus it is common for one or all of the nodes to crash where in the future the underlying cause will be dealt with in normal operation of the chain.
What's next
- The Sagapython Users Guide is long overdue for an update reflecting changes in syntax since its inception. It is not currently distributed in the repos, but will be made available once updated.
- The account negotation assignment algorithm and the associated transaction queues and flows form the means to assign accounts to shards and accomplish the ownership transfer in an efficient means. The graph search algorithm for account negotiation, ownership transfer mechanism, and per-transaction account use discovery will be described in a technical document.
- This release proves out the underlying core functionality needed to make a large scale, scalable, secure, crypto blockchain, with an execution "shardable" metaclass object model and account model. Next steps implement the various components to move from a core functionality to our goal of a full mainnet crypto blockchain with all of Sagachain's unique features, enabling a large variety of new applications.