Hi everyone! My name is Sean Rowan and I’m the co-founder and CTO of Flare. This first post conveys a short introduction to Flare and how we use Interledger with Flare.
Flare is a new distributed network that uses the same style of consensus as Ripple and Stellar (Federated Byzantine Agreement). However, Flare is Turing-complete and can run full smart contracts - the first release of Flare runs the latest Ethereum Virtual Machine.
A Flare Network is underpinned by the Flare Consensus Protocol (FCP), which is a new construction of Federated Byzantine Agreement (FBA) consensus. An FBA construction does not rely on economic mechanisms for securing consensus because it enables individual nodes to independently effect quorum slice decisions; market forces cause overlaps of quorum slice decisions on the network and this gives rise to the network-wide rule for consensus. FCP achieves fairness by being both leaderless and totally-ordered, making it excessively difficult for an attacker to influence which of two transactions will be ordered first in a transaction set. FCP is also asynchronous and achieves very fast finality. These properties make FCP a compelling model for internet-level Turing-complete consensus.
FCP has a complete mathematical proof of its Byzantine fault-tolerance and it is currently under peer-review; we will publish the whitepaper upon completion of this process. FCP and the EVM Flare Network have also been implemented to production-grade standards as of December 2018 and we are currently undergoing our latest round of cybersecurity audit of our codebase (written entirely in Golang) by a cybersecurity firm that contracts for NATO and many financial institutions.
There are numerous deployments that we have in mind for Flare, and we don’t want to make any particular restriction on how node operators in a Flare Network are remunerated. Concretely:
The Flare Network is not releasing a native token.
We want to enable different node operators to accept remuneration in different currencies of their choice in a single Flare Network.
We even want to enable a single node operator to be able to accept different currencies.
We analysed several options for handling node remuneration, and Interledger matches up perfectly with all of our requirements. We are early-on in our progress with Interledger, and we wanted to open up the conversation now in order to introduce ourselves and get feedback on our use of Interledger as we deploy ILP for Flare node remuneration.
Does the VM need to be deterministic or could this network handle non-determinism?
A couple of questions on the model:
What exactly do users pay node operators for? Is the transaction fee based “gas” or a concept like that that measures the complexity of the transaction?
Do node operators set their own price or would you expect each of them to have the same price?
When one operator broadcasts a transaction to the other node operators, does the broadcaster have to pay the others? (If they don’t, would users be incentivized to submit transactions to the cheapest of the operators?)
Do users need proof that they paid a particular operator?
The transaction fairness property of the Flare Consensus Protocol enables sources of randomness to be safely generated directly within a self-contained Flare Network. Then non-determinism can be achieved on Flare by incorporating the sources of randomness into a contract in the VM.
The transaction fees will be based on gas usage, and the payment model will support pre-paid or monthly subscriptions of gas ownership. We are currently working on full documentation for this accounting aspect and will revert fully soon.
The system is flexible on this and provisions for node operators setting their own prices within the same Flare Network. However, a node operator can’t change their pricing instantaneously, and only at predefined checkpoints. Similarly, changes of independent quorum slice decisions of nodes on the network take effect at predefined checkpoints instead of instantaneously.
Users will only directly pay the endpoint nodes that they submit transactions to, in order to simplify the user experience. These endpoint nodes make their own quorum slice decisions on the Flare Network, and pay a portion of the money that they receive from the user to these ‘downstream’ nodes, based on gas usage by that user.
The system would use this proof as a signal for linking gas allocation on the network to the user’s payments.
I see. But Flare couldn’t accommodate non-deterministic VM functions like calls to external HTTPS services, right?
Would you actually need proof if each node operator is going to pay the others for a particular user’s transaction? Seems like each node would just decide for themselves whether they had gotten enough to include the transaction, rather than needing proof that the user paid others. (I’m asking this because we don’t currently have a protocol that provides non-repudiable proof of payment but we could build something using streaming receipts).
An EVM Flare Network contract can’t directly interface with an external HTTPS service, because all of the nodes in the EVM Flare Network aren’t guaranteed to get the same result when they query the same HTTPS service. However, Ethereum has this exact same property and there are oracle systems that have been developed for Ethereum which can be directly leveraged in the Flare Network for reading external HTTPS services.
We’re exploring the idea of including an automated percentage-based fee on all gas transactions in the system that would support the ongoing development of Flare. The code that the node operators run would check that the Flare fee has been included before allowing that user’s transaction to propagate. I am highly interested in working with the streaming receipts mechanism to support the Flare fee feature, and am keen to discuss this further.
I should have emphasised that we are keen to progress in stages with our Interledger integration, and we’re starting out with getting the node operator remuneration fully working first before moving on to the Flare fee mechanism which may or may not require the receipt proof. I will post more information in the coming days about a concrete design for how we’ll deploy Interledger + Flare in stage 1 for node remuneration. Your comments and questions have already been very helpful for me in thinking through our integration and I’m looking forward to getting our ILP+Flare integration off the ground soon!
A completed spec of the Flare Network is located here: https://flare.ghost.io/theflarenetwork/ - the information in the above ILP forum posts was from early in the development process and can be considered deprecated now.
