bigknife/fssi

finacial service infrastructure

fssi's Issues

send transaction

warrior processes transactions

1. define nymph jsonrpc for submit transaction
2. implement nymph's sendTransaction

publish contract with source code

CLI01 - contract lib improvement 01

1. kv store's method signature:

def put(key: Array[Byte], value: Array[Byte])

2. add current invoker account info to Context

create contract from contract file

check sql to avoid undetermined command being executed

for the sql store implementation, we should check the sql used by executeQuery or executeUpdate, all sql should be deteministic.

run smart contract

• add CreateTransaction runContract into tool

• add create run contract program

• integrate program to tool

warrior handle new account

contract sdk

implement query node

a query node also is a p2p node, but not handle consensus message.

1. synchronize latest ledger and snapshot
2. provide query service:

• query account snapshot
• query account's contract
• query transaction state

output CreateTransaction's result to a json file.

add an arg, if it's set, output the transaction json rpc message to the file.

fssi_tool CreateTransaction transfer -o ~/tmp/transfer.json

run consensus

after transaction evaluated to moment, we pool the moment, when the pool is full or timeout, we build these moments to a proposal, then run consensus to validate the proposal.

if the proposal totally agreed, every node should commit the proposal, all transaction will be settled down.

improve gossip effeciency

contract invoke another contract

think about contract invoking by another contract. now a contract can be invoked only by user.

validate the side-effects of the transactions

now, we only check the tx, then post to consensus engine. we must evaluate all the txs, and post the result hash with the txs to consensus engine.

refactoring-3

create chain

provide a command to create a chain, e.g.

tool CreateChain --chain-id=testnet --working-dir=/data/testnet

transaction id generation

transaction id

user post a json rpc request to a edge node, and get a reponse from the edge node synchronously, which involves a transaction id, generated by the edge node.

user can query a edge node to get a transaction's status by its tranaction id.

• client never create the transaction id, it's up to edge node.
• implement a method named queryTransaction to edge node json rpc services
• implement a command name QueryTransaction to generate queryTransaction jsonrpc request
• on core node, every transaction should be kept, and their results should be deterministic

use mill as building tool

http://www.lihaoyi.com/mill/index.html

transfer token to another account

• add CreateTransaction command to tool to create a transfer token transaction

• add Transfer token method to edge json rpc

• run consensus to create block

redefine assets layout

now, the layout of assets of an account is plain, every contract can act on every assets key. It's not too safe, and the previlege is too loose.

Try to redefine the assets layout to enhance the safety.

nymph server

a json rpc server for nymph.

Note: MUST follow the JSON RPC 2.0 Spec

compile smart contract

compile smart contract:

tool CompileContract --source-code /source/code/directory --output /jar/directory

1. compile source code
2. check un-derterminded byte codes, if they exist, compiling will be failed, print the undetermined code info.

• add CompileContract sub command for tool

• merge compile contract implementation from @BeleiveSong

compiling contract as a feature of tool

warrior ast

make ast for a warrior node

warrior server skeleton

warrior server skeleton.

1. receive messages from nymph
2. gossip messages to all warriors.
3. handle messages.

refine contract parameters

1. contract.parameter types should be reverted to it's old version.
2. contract.parameter is different from contract running parameters. contract.parameters is logic and facing to contract invoker, contract running parameters is used to running a contract in jvm, facing to sandbox(runtime) and contract developer.

censensus engine shoud be consistent with local store

problem

when transaction failed, local store will be rolled back, but the consensus engine is on the right postion, so when a new proposal is to process, the consensus should reject the new proposal (because the proposal's slotIndex has been reached agreement)

invoke another contract in a contract

refactor scp

remove scalap dependency, implement scp inside the whole project.

reset tool program's logs

catchup current chain height

validate world state

improve warrior node

provide more features to support query node.

periodly push ledger to cloud drive, so other nodes can download ledger archives from cloud drive.

support read-only contract method invocation

now, all contract invocations will be post to consensus engine, but it's not neccessary for readonly contract methods, so it's important to seperate them.

if the contract method is readonly, only invoke them, and render the results to client.

publish smart contract

• add publishContract to tool CreateTransaction

• handle PublishContract transaction to reach agreement

register account

call register json rpc method to create an account

1. implement corresponed interpreter.
2. implement register jsonrpc service.

publish contract

handle transaction

warrior node should handle the trasaction message.

validate sql store's consistency

fssi account should be compatible with bitcoin account

gurantee idempotency for every jsonrpc request