Currently In progress
The Genesis block needs to be written in the BlockStorage
Instead of users requesting information from a centralized server. Users request information from other “peers” (nodes) that share information amongst themselves.
Users will now start a node and have it connect to other nodes in order to participate to the network.
Users will no longer be at risk of having invalidly crafted transactions rejected in order not to be broadcast and save me the cost of verifying the signature.
Users will now have transactions with invalid signatures be rejected in order not to be broadcast to the network.
The ability to know what a transaction looks like so serialization can happen properly, deserialize and interact with them.
Users will now be able to start a node and have it catch-up with the rest of the network in order to join a network at any time.
Blocks will have multiple transactions in order to implement logic that can handle it.
An index file to use in order to have fast/constant time lookup of block data.
A signature scheme that is efficient and composable in order to sign my blocks and eventually my transactions.
A UTXO data structure that contains data consensus in order to efficiently draw and store new data from/to it.
Node operators can create a transaction that marks their UTXO as “frozen” so that they can use it as collateral for running a validator node.
Stellar Consensus Protocol code (SCP) integration into AGORA in order for the basic block of consensus to work.
Users can now run AGORA on windows devices
A collection of validators combined together in a smaller group (or quorum) and each of these validators can can then validate that each other is in fact telling the truth. We have decided to use SCP (Stellar Consensus Protocol) to assist in the implementation of this. Using SCP out of the box calls for quorums to be manually configured by the user. We are taking things a step further and improving the pre-existing foundation of SCP by creating our own modified version of it that automates the quorum creation process. By automating this process you no longer have to worry about who to trust or how trust is created. The only thing you need to worry about is having at least 40,000 BOA in your possession. You can easily set things up and forget about it.
Previously a Validatorr would broadcast messages to its connected peers through a function. The issue was that the list of peers as a subset of Validators. This implementation changes that.
This gives us the ability to create documentaion related to PRs
Instead of having the pre-image reveal happen on 'putTransaction' it will now be done on a timer.
Currently the nomination protocol is handled by SCP, but we have to assess the changes required (if any) that come with making the network open.
Agora : Node implementation for BOA CoinNet
Similar to Bitcoin, BOSAGORA Full Nodes receive both blocks & transactions followed by propagating them to their peers. Full Nodes do not take part in the consensus protocol nor do they create blocks, they are simply able to make sure that the received blocks have been accepted by the network.
A Validator is a superset of a Full Node. It does everything a Full Node does plus it has the added ability to participate in consensus with other Validators. Its function with regard to the network is similar to that of Bitcoin’s “miners”.
Flash Layer functionality adds the ability for Validators to handle “off-chain” transactions, by using their additional stake to create payment channels, which can then be used to conduct transactions without committing them to the chain. Ideally this layer would focus on microtransactions. As a result, fees & node rewards need to make the Flash Layer attractive.
In this phase of development we will begin transitioning from our ERC20 based TestNet to our personal MainNet known as CoinNet. Once this development is complete all prexisting ERC20 BOA tokens will be converted to BOA coins.
We plan on replacing the industry standard Smart Contract with our own contract solution known as Trust Contracts. For Trust Contracts we plan on using WebAssembly (WASM) as it allows for easy validation, execution, and security when paired with D-Language.