Smilo v1.9.2.2 — Smilodon Populator — Autonomous community (GETH 1.9.2)
We are super proud to present our latest release of the Smilo Blockchain Platform: The Autonomous Community.
Announcement
Over the last two years, we “the maintainers and developers” of Smilo Blockchain Protocol have created and launched the mainnet of the Smilo blockchain protocol through a corporate structure of initially a Dutch entity called Smilo Platform BV (now rebranded to Code Coyote BV). In January last year, we set up a Smilo Foundation (closing activities by the end of 2019). Like with many startups we have experienced some issues around organisation and financials which resulted in a lack of trust and transparency, which is the core value that we are committed to as a platform but also that we need to warrant towards our community.
Therefore part of the team has decided to exit both entities and to organize this initiative in a way that truly reflects our core values as a team. Inspired by the OpenEthereum DAO, we are changing the Smilo governance model to a Decentralized Autonomous Organization.
Because of this changes on our structure, we would like to introduce you to the new tools that we have put online in order to allow our users to be secure and be able to follow us on this new journey as a DAO.
Old sources (deprecated):
smilo.io — Website
explorer.smilo.network — Block explorer
smilowallet.io — Online wallet — MEW v4
github.com/Smilo-platform — Source code
New Autonomous Community sources:
Smilo Secure Wallet — Smilo Secure Wallet stores your private keys safely in a local, isolated, and secure vault on your device to protect your account
wallet.smilo.foundation — Online wallet — MEW v5
explorer.smilo.foundation — Block explorer
github.com/smilofoundation — Source code
smilo.foundation — Website
launchpad.net/~smilo — Ubuntu packages for go-smilo blockchain
The new release — Autonomous community
In order to better explain our new release, we are going to quickly review the Smilo Blockchain Architecture and explain what is new.
Smilo Architecture:
It comprises of four components namely:
1. Go-smilo Node (Modified GETH client)
It is designed to be a lightweight blockchain that takes advantage of the R&D and battle-tested Ethereum GETH 1.9.x PoW Blockchain. It is updated regularly such that it is in line with the future GETH releases.
Some of the modifications done to the Smilo node are:
- Created a new consensus algorithm and integrated existing ones.
- The P2P layer is modified to allow connections to/from specific pre-set nodes.
- The block generation logic has been modified to have two states: `public state root` and `private state root`. Private transactions do not allow the transfer of tokens, transfer of tokens privately should be done via ZK Snarks public smart contracts.
- Block validation logic changed to handle `private transactions`
- The dual token system introduced. XSM (Smilo) and XSP (SmiloPay). Users pay for transactions with XSP and Gas deposit. The gas deposit is returned if all goes well.
2. Vault Transaction Manager
Vault transaction manager refers to a general-purpose system that helps to submit private encrypted smart contracts via P2P to restricted parties. It uses the TweetNACL curve 25519 plus a random nonce to encrypt the smart contract state, thus hiding the transaction contents from other peers in the network.
3. Smilo Blackbox
The Smilo Private Vault (SPV) is P2P software that stores and shares your private smart contract state across the network. It is a software program written in Golang that makes use of the Ethereum P2P capabilities to find peers and transfer encrypted data.
The protocol will search the network and identify the Vault peer that matches with the peer that is supposed to receive the data at the time of creating the transaction. During this transaction, the smart contract state will never be saved on the blockchain, only a hash that is consequently used as a checksum will be stored on the blockchain.
With this hash, nodes can validate whether they have received a valid state or not. A not valid state is automatically refused and the peer who sent the faulty data is blacklisted temporarily.
4. Consensus Algorithms
A consensus algorithm is a computer process which helps machines to achieve agreement among systems or distributed processes.
The purpose of a consensus is to aid in achieving reliability and security in a network that has multiple unreliable nodes.
BFT — Byzantine Fault Tolerance
A Fault-tolerant system where components may fail and there is imperfect information on whether a component has failed. It
Byzantine fault:
- a fault presenting different symptoms to different observers
- occurs in systems that require consensus
Byzantine fault tolerance:
- defend against failures of system
- Reach consensus if failures are < 1/3
Sport Consensus State Transitions
The algorithm chooses a fullnode (the speaker), in a round robin fashion, sticky or VRF (under development), which proposes a new block to the fullnodes along with a PRE-PREPARE message.
When a fullnode ACK the reception of this new block and the PRE-PREPARE message, a fullnode verifies whether the proposal is valid and enters the PRE-PREPARED state, the fullnode broadcasts a PREPARE message. The PREPARE message is to ensure that fullnodes are working on the same block and round. Upon receiving 2F+1 PREPARE message the fullnode enters the PREPARED state and broadcasts a COMMIT message. The COMMIT message informs the other peers that it has accepted the proposed block and is ready to insert the block into the chain. After receiving 2F+1 COMMIT messages the fullnode enters the COMMITTED state and attempts to insert the block into the chain, if successful, the fullnodes enters FINAL COMMITTED, the block is persisted with all the signatures from all nodes that participated in this state transition and moves to the next sequence.
A sequence can contain multiple rounds, however, there is only one sequence per block. A round change can happen if there is a timeout, the proposal is invalid or the block insertion fails, upon these events the fullnodes enter the ROUND CHANGE state and waits for 2F+1 ROUND CHANGE messages before moving into a new round.
What is new?
Smilo v1.9.2.2 is shipping two new consensus algorithms, SBFT DAO and IBFT DAO.
SBFT (Sport BFT) and IBFT (Istanbul BFT) DAO are similar consensus that differ mostly on the minimum required quorum required to validate a block (66% for SBFT) and improved codebase with more tests and important changes that make this consensus more readable and easier to maintain. SBFT have also changed some name conventions, validators are called fullnodes and proposers are the speakers.
With this release Smilo empowers our Enterprise Blockchain users to have fullnodes/validators Governance in the Smart contract level, but what does it mean exactly ?
Smilodon Populator 1.9.2.2 will enable companies to have the ability to govern the fullnodes/validators on a network through a smart contract, deployed upon network initialization or via a planned hard-fork.
The new release approach to network is leveraging the use of smart contracts, this smart contracts are responsible to manage the fullnode/validator set and also controls who have access to the network. This results in a on-chain governance that enables the consortium responsible for the maintenance of the blockchain to fully customize the governance mechanism of the network.
This modular architecture, composed by the smart contracts, allows enterprise blockchain users and consortium of companies to decide and precisely define the governance mechanism through which the fullnode/validator set is maintained.
The consortium can setup a Governance mechanism, this should then be configured with a number of smart contract interfaces that will consequently allow the consensus mechanism to access the fullnode/validator set when creating new blocks and validate that each user is doing the right thing in a distributed, transparent and decentralized way. To explain this better, we have divided it in two sections:
1. Governance of the network set
Set of Network Fullnodes/Validators.
The set of fullnodes/validators who create and validate blocks are stored in a smart contract. Fullnodes/Validators are identified via their public address.
Addresses not contained in the list should be prevented from creating blocks but should be able to view and submit transactions on the network.
The initial configuration of the list is defined at the genesis file. It should be noted that this list must be non-empty, as only members in the network can vote to add new fullnodes/validators. The size of the list is dynamic. However, the details of the governance processes (e.g. the maximum size of the list) is defined in the smart contract.
2. Open interface allows many governance mechanisms to be further implemented and customized, suiting all enterprise requirements.
Modular Governance.
The logic in the smart contract sets the rules to add and remove fullnodes/validators from the white-list. Thus, the user can customize the governance of the member set writing the contract functions which satisfy a defined interface. Examples of variables that can be defined at the contract level are:
- The minimum quorum and threshold required to add/remove nodes.
- The minimum and maximum size of the white-list.
- The voting mechanics to add/remove nodes.
We are currently working on a small demo that will explain it in more detail, stay tuned.
Acknowledgements / gr33tz
This amazing work, was a result of many months of unpaid research.
Launched on March 8th, 2019, Smilo is a cryptocurrency focused on making permissioned ledgers obsolete.
We believe that everything that can be done in a permissioned blockchain, should be possible also in a public blockchain. We see a future where permissioned ledgers will soon be obsolete.
The Smilo developers want Smilo to be (Open, Public, Border-less, Censorship Resistant and Neutral). Smilo was launched without a premine, ICO, or founders rewards and relies on donations to support the long-term development of the project.
Our unpaid development team have been working hours around the clock to understand, merge, refactor and test existing codebase created and maintained by the Autonity developers. We would like to thank all their developers and team for the hard work and excellent code base, full of tests and that is under active development, we love what you are doing s2.
The official list of go-ethereum Authors, without your individual contributions this would never be possible.
Vitalik Buterin, Thank you for your pure approach to blockchain. Thank you for truly caring and calling out the greed and the scams. Keep up the good work!
Smilo’s development is not motivated by profit for either its developers or early adopters. In order to finance the project and guarantee its future, we invite everyone who sees potential to consider donating/investing to the project, and we hope that the vibrant cryptocurrency community will help Smilo to achieve its goal of making permissioned ledgers obsolete.
#NO-ICO #ICO-FREE #NOT-AN-ICO
Be part of the Smilo hybrid blockchain movement!
go-ethereum <3
