Parallel processing is definitely possible with our stack and worth trying.

Currently the blockchain is capable of processing low 100's of simple transactions per second.

This implementation could be used to significantly increase the throughput of the blockchain, based on the amount of cores available.

How would it work ?

A few modifications would be needed to support this.

1 ) The user's transaction must detail all the values on the blockchain it will be altering. Let's call this a claim.

2 ) The begin_block method would need knowledge of all the transactions from the block it's processing.

3 ) n lightweight contracting processes to run transactions in separate threads, these do not write to disk, but instead return the list of writes to the ABCI app.

Lifecycle of a block

1. begin_block is called, retrieves all transactions in the block.
2. Sort transactions :Make two lists, in one - transactions where the claim does not intend to modify any values held by other claims. These can be processed async. The other list contains claims that contain overlapping state modifications.
3. run the async transactions in other threads async. if the result of the transaction results in writes that differ from the claim, fail it, otherwise it's ok to write it, return tx output to the main process. Add the output to a structure like this. :

{
    # This tx is processed by a side process.
    "tx_1"{
        "parallel": true,
        "success": true,
        "data"{...
        } // this is the tx output to return in the deliver_tx response
    },
    # This tx was was rejected due to invalid claim
    "tx_2"{
        "parallel": true,
        "success": false,
        "data"{...
        } // this is the tx output to return in the deliver_tx response
    },
    # To be process as normal, in sequence at deliver_tx
    "tx_3"{
        "parallel": false
    }
}

4. The begin_block function completes and the blockchain now iterates through all transactions.
5. Soft apply all async state results to the db
6. deliver_tx is called for each transaction, for async txns the appropriate data is returned in the response, as if the transaction was normally. Sync transactions are processed normally, however the claim is still validated against the transaction result.
7. end_block and commit are called.
8. all state-changes are hard-applied

Transaction environment relates to how we create verifyable, deterministic randomness in smart contracts.

Also related to using the time which comes from the begin_block event. We need to decide how we are replacing the legacy way of creating a block hash, salt etc.

To get the process_tx logic to work, I commented out a bunch of stuff. Some of this had to do with signature and hashes in the final return object.

We need to determine what we want to include here and what we can permanently do without.

We should rename the currency contract to something else. Because if we at some point want to interact with another network like Lamden, it might be an issue if their TAU and our XIAN are both the same contract.

Either we name it xian if we are sure about the name or we call it something more abstract.

Would be more nice I think if we can provide a swagger ui for our API.

CometBFT has an approach for time. Important thing here is that it will allow for deterministic replication of state across nodes when compiling blocks.

https://docs.cometbft.com/v0.37/spec/consensus/bft-time#:~:text=Time%20in%20CometBFT%20is%20defined,Time%20%3C%20H2.

Time is passed in the req object on the begin_block event.

Do we want to produce empty blocks?
https://docs.cometbft.com/v0.38/core/using-cometbft

https://github.com/xian-network/xian-core/blob/9defae5b9189cc376e8aec4724e91c241d292b3b/src/xian/xian_abci.py#L322C13-L334C48

We need to decide how we're going to appoint validators, what the requirements will be and agree on a high level design for this.

That said, if the transactions contain some internal value, like an order/nonce/sequence number, the application can reject transactions that are out of order. So if a node receives tx3, then tx1, it can reject tx3 and then accept tx1. The sender can then retry sending tx3, which should probably be rejected until the node has seen tx2.

https://docs.cometbft.com/v0.38/core/mempool

Let's have a discussion about the structure of the project and how we can make it as nice a place to work as possible.