May 11, 2019
Feirm Dagur — A new type of blockchain architecture
Feirm’s Dagur protocol has been in talks since early 2019 and will be developed with Go. It’s intended purpose is to extend the Feirm ecosystem. Let’s be real here, the current C++ codebase is dated, and the majority of forks lack features. This isn’t the only turning point however. If you’ve been around recently in the cryptosphere, we’ve had to apply our fair share of patches for some really nasty exploits.
The Past Exploits
Just to name a few, throughout December of 2018, an exploit was made aware to us from DACH Coin, where an attacker managed to create coins out of thin air, due to a check being commented out in the code to ensure that the staking output and transaction fee was valid. We discovered that Feirm was vulnerable to this, and released a wallet upgrade on the same day it became aware to us.
A further exploit were the “Block Spam” attacks. If you are interested in the attacks, you can find the article published by Decentralized Systems Lab below.
But why Go?
The Feirm Dagur protocol will be developed with Go, and with good reason. For starters, the main reason is that Go was built for concurrency and is very suitable for designing highly distributed systems. Projects such as Ethereum and Hyperledger provide support for Go.
Secondly, Feirm’s services are written in Go. Our Marketplace API is extremely scalable due to containerisation and deployment with Kubernetes. This also applies to our Payment Processor, which is written in Go. And you may not even know, but our load balancer is even written in Go! It makes sense to stick to a friendly ecosystem where the primary language is highly versatile.
Lets Go all the things!
Thirdly, Go has excellent support for compiling cross platform applications. Small binaries can be compiled for Windows, Linux, MacOS and ARM devices. Those are just a few to name! What does this mean though? It means that you can run a full blockchain client on a single board computer like the Raspberry Pi!
Your hardware shouldn’t limit your ability to make an impact by supporting the network.
There are tons of more reasons why Go should be used, but I won’t cover them here as they aren’t specifically related to the blockchain architecture use case.
What will the Dagur protocol include?
Since this will be a brand new network, it is still in discussion about the features to be integrated. The primary discussion has been about the consensus mechanisms, as this is the backbone for the networks operation.
Delegated Proof of Stake (DPoS)
This consensus mechanism varies quite a bit from the others out there. It requires for stakeholders to vote for “delegates” who are responsible and rewarded for maintaining the network, validating transactions and generating blocks to be added to the blockchain.
Each stakeholder is only allowed 1 vote per “delegate” where the “delegates” with most votes are elected into the top 51. Stakeholders can vote for as many “delegates” as they wish. It just means that their overall voting weight is diluted based on the amount of potential “delegates” they vote for.
Voting is an ongoing process throughout the network meaning there is an incentive for them to carry out operations at their highest function or they risk losing their position to a “delegate” waiting in the queue. Scoring systems are also available to assist stakeholders in assessing the quality of “delegates”.
The group of 51 “delegates” on the network are chosen in order to be able produce a block and this cycle happens right up until its time to vote for the next set of “delegates”. Failure for a “delegate” to produce blocks on time will negatively impact their reputation score and potentially mean they are voted out of the “delegate” position.
What’s the downside to using DPoS as a consensus mechanism? Well, full decentralisation cannot be achieved. The more witnesses there are producing blocks, the more the network slows down. A perfect balance must be found between the number of “delegates” and scalability of the network. To try and combat the risk of centralisation, an enforcement would be made so that there can only be 51 active “delegates” running on the chain.
The Voting Scenario (Simplified) — Courtesy of a community member
Bob can nominate himself as a “delegate” with his 100,000 coins and rightfully so as he purchased the coins for himself. Bob knowing that for every other delegate that he votes for this reduces his own position to be a delegate. He needs to make sure that he doesn’t vote for too many delegates that pushes himself outside of the top 51 candidates as his voting weight would be too diluted to maintain his own “delegate” voting position.
The vote can be in your favour too, if you have enough coins of course!
The Voting Scenario (Detailed)
Alice wants to become a delegate and lets say as an example she needs 200 votes to become one. Alice however is friends with Bob and Charlie, both of which own 100 coins each (100 voting weight each), with a combined total of 200 voting weight between them. Both of them want to help Alice out and decide to vote with their full staking weight. So that means Alice now becomes a delegate as she has gotten 200 votes.
However, there is a friend of Alice who wants to also become a delegate. He’s called Dennis, and needs 200 votes to become one also. It also turns out that he is also friends with Bob and Charlie. Once again, Bob and Charlie want to help him out, and decide to vote. Surely there is an issue with this though, as both have already voted for Alice?
The solution here is to distribute the votes between candidates Bob and Charlie have decided to vote for. So instead of putting 200 votes forward for each candidate, they can only put forward 100 (50% or half of their individual voting weight), as they’ve decided to vote for 2 delegates. This action continues for however many delegates they wish to vote for. Simply, their voting weight decreases for the more people they vote for. If they decided to vote for 4 delegates, then their voting weight for each of them is 50.
How can we further ensure that a “delegate” is committed to the role?
A simple addition to include when the user goes through the “delegate” creation process is to make them lock up a portion of their funds to act as collateral against the network, similar to the way a masternode works by locking funds. If the “delegate” misbehaves (doesn’t produce blocks/excludes transactions/not high uptime), then that collateral is lost and subsequently they lose their “delegate” position. This is how PoS is secured — if a user tries to tamper with the network, their stake is taken away from them.
How do I become a “delegate”?
All that’s required to become a “delegate” is for you start up a node, register a “delegate” name, and then post a proposal about why people should vote for you as a “delegate”. If you receive enough votes to become a “delegate” you will begin to forge blocks on the network and earn your reward.
Utilising DPoS with the Dagur protocol
Transactions
A user typically forms a transaction, signs it and then transmits it to the network. From this, they are stored in a transaction pool until a “delegate” comes along and forges a block containing transactions loaded in from the transaction pool. The “delegate” will then relay that block to the rest of the network so that other peers can verify it and include it with their copy of the blockchain.
Block Speeds/Delegate Rounds
If a block time of 10 seconds is enforced throughout the network, then it would take approximately 510 seconds for all “delegates” to have produced a round of blocks. If the “delegate” is not available to generate the next block, then the next “delegate” in the round would take over, causing the block time to increase to 20 seconds temporarily. The more “delegates” that are offline, the longer it will take for blocks to be generated.
Voting Rounds
Every 24 hours, votes are tallied up from the stakeholders, and the set of 51 new delegates are chosen and begin to start forging on the network. Voting is a one time occurrence though and carried out on the blockchain, so your vote stays the same unless you change it.
Network Fees
A common issue with blockchain ledgers is transaction spamming. If a user was spamming rapid amounts of transactions to the network, it would increase the size of the blockchain quite quickly. An attempt to combat such attack is charging a processing fee for transactions which go directly to “delegates”. Fees should be set dynamically, as seen with Bitcoin, so that under low network load, sending a transaction is extremely cheap, but during heavy network load, the cost to send a transaction increases. The goal of this is to act as a deterrent for those who want to think about spamming the network as they’d most likely end up spending more in transaction fees.
You’d be making the delegates happy!
What if a delegate chose to not process my transaction? As the “delegate” charges a fee to process a transaction, it is up to them whether to include your transaction in their block. However, if they choose to reject your transaction, this makes them a bad actor, and eventually they will be voted off of the network due to being a dishonest node. The only repercussion if a “delegate” chose to not process your transaction, would mean it takes a little bit longer to be included in the next block.
How do I as a Feirm stakeholder earn rewards?
If you are unable to make it into the “delegate” position, or just want to be a stakeholder on the network, you make your rewards by voting. It is in the “delegates” best interest to stay in their position, which is why its common for them to pay out a percentage of their daily earnings from “block forging” to their voters.
Example Figures:
==================================================================Current Supply => 6,130,045 coins
Block Time => 10 seconds
Alice => Delegate - Earns 190 coins per day from forging
Bob => (Stakeholder) - 100,000 coins
Let’s use the details above where Bob has 100,000 coins. You (Bob), decides to vote for a Alice who is a “delegate” and shares 40% of her daily rewards to her voters. 40% of her daily reward is 76 coins and will be distributed between her voters voting weight (%). In order for a “delegate” to be in the top 51, they need about 2% of the overall voting power.
Current Supply x 2% = 122,600 coins in votesTo work out how much Bob’s coins are worth against the rest of the votes, and then calculate how much you can earn per day, you do this:
Bob's coins / 122,600 votes = 0.82 coins
0.82 x 40% of Alice's daily reward = 62.3 coins per day added on top of Bob's existing 100,000 coin balance.The calculations above are only for when you vote for 1 “delegate” if you distribute more votes, you can receive more income from the different “delegates” who are offering a portion of their daily payouts.
As an investor (stakeholder) on the network, all you need to do to secure income is to vote for the “delegates” who you see fit for the role.
Putting a concept into reality
We have been extremely excited with this idea, and decided to build a proof of concept DPoS blockchain to ensure we can meet our goals, and we managed to mock this blockchain up from scratch with basic block generation and networking.
Both of the nodes pictured below are both running on a local machine.
As you can see, a new block was being forged by the main node every 10 seconds, and then was transported to the other nodes on this local machine.
Your Say
What do you think about the Dagur protocol? Please let us know your thoughts in our Discord!
We’ve created a vote utilising the governance feature of the Feirm blockchain. Whether you are in favour or not of the planned Dagur protocol, we want to hear your opinion! Just open up the Debug Console of your Feirm wallet and run the following command based on your vote.
Yes:
mnbudgetvote "many" 20408b4068b2b24296358892ba9e777584986828ce546f30965003f94bc20238 "yes"No:
mnbudgetvote "many" 20408b4068b2b24296358892ba9e777584986828ce546f30965003f94bc20238 "no"Proposal:
[
{
"Name": "Dagur-DPoS",
"URL": "https://bit.ly/2H5u3TX",
"Hash": "20408b4068b2b24296358892ba9e777584986828ce546f30965003f94bc20238",
"FeeHash": "7ad4647d306d4857bf1e5d1db1cab0ead3e6f3fed8fa3bae9a7f2a81782b7a23",
"BlockStart": 388800,
"BlockEnd": 432001,
"TotalPaymentCount": 1,
"RemainingPaymentCount": 1,
"PaymentAddress": "5t1ZW572NozpUjV9bAcWeVuZWfg8P6HExT",
"Ratio": 0,
"Yeas": 0,
"Nays": 0,
"Abstains": 0,
"TotalPayment": 10.00000000,
"MonthlyPayment": 10.00000000,
"IsEstablished": false,
"IsValid": true,
"IsValidReason": "",
"fValid": true
}
]Final Words
Overall, it seems that utilising DPoS with Dagur is a great combination to form a robust, democratic network, where the stakeholders are in control. And for this reason, you do not see masternode implementation mentioned elsewhere in this protocol, as the blockchain is self-governed by its stakeholders.
By no means is any of this set in stone as of yet. We are still researching the different options out there, but wanted to let you know what is currently going in terms of long-term plans for the project!
Thank you for reading!
