Fantom ICO Code Review by Andre Cronje
Share this article
The Fantom ICO review that we published offers a high-level view of the high-performance blockchain project, so I won’t spend too much time talking about the ICO goals and the industries Fantom wants to work within. Today’s goal is a code review to see where they’re at with their tech progress.
Fantom claims to be an improved version of a DAG model for speed and infinite scalability. They accomplish this via the Lachesis Protocol. Transactions are confirmed with a DAG to maintain consensus within the decentralized Fantom network.
The asynchronous time based DAG model gives them scalability. I am curious how concurrency and network propagation is handled as well as double spend attacks across multiple nodes. However this is left unanswered at this point in time.
Their smart contract language is scala based.
The core is the Lachesis Protocol. This data is not required to be saved by all nodes.
The design here is two fold, at the first layer we have the asynchronous time based DAG, simply put, this allows any node to confirm any transaction if a preceding transaction is known or present (similar to the UTXO model of BTC based eco systems).
It is this system that allows for concurrency, so each node can stream transactions as fast as they can as long as they have knowledge of the previous transactions. I am unsure at time of writing what happens when a transaction is found without a preceding transaction present and how this even propagation occurs. This is a key problem to solve, as often network latency is one of the key detriments to throughput.
From the above description, we can note that Time To Finality (TTF) is not present in the above layer. Finality is achieved by the Opera Chain. This layer implements Delegated Proof of Stake to elect Validators. These validators then identify path proofs. Path proofs are best compared to pathing algorithms in games, it’s about a) finding the shortest route, b) finding the route with least obstacles and c) finding the route that is appropriate for the characters that need to traverse it.
The Opera chain validators do something similar to find the DAG route that best describes all of the properties it is wanting to prove. This includes the path with the most valid transactions, that has the strongest reference to the previous opera block, and the route which if reversed would affect the most balance in the system.
To identify these, there are two sub systems, Atropos, and Clotho, in all honestly I am not 100% sure how this part works, from my understand the one is allowed to propose potential blocks and the other validates these, if enough agree (presumably via the same dPoS consensus) then the proposed block becomes the next Opera Chain block. This block, provides Time To Finality.
So now we have concurrent streaming transactions, each connected, time based, on their previous transaction, and given finality when a opera chain block is found. So in a perfect environment, where we had 100 nodes, each is fully aware of each preceding transaction, there are no conflicts, no double spends, no multi attacks, and the shortest proposed route is the first proposed route, they can achieve 300k transactions per second.
At this point, we have a lot of unanswered questions, so let’s jump into the code and see what we have available.
The Virtual Machine currently, looks like our core questions won’t be answered today, but let’s see what kind of caliber code we are looking at.
Not the active repo, this is a checkbox repo. I like to see the development history and get an idea of what kind of effort has gone into it. However for now, we only have a snapshot, so let’s look at the proposed snapshot.
Good documentation on all the OP codes
Copyright notices were added today. I’m assuming the code wasn’t developed today. Good comments, nothing interesting, but nothing bad.
Quite a bit of copy paste, this could have probably been refactored.
Quick little VM tester, I like that they added that in.
I would have loved to see this implementation, sadly it’s just a stub for now.
Not seeing any of the developers that coded these segments on their website, and the copyright belongs to the developers, which is weird.
And that’s all we have.
Fantom Code Review Conclusion
I’m left with more questions than answers after going through the code, I like the idea, I like that they have a strong focus on their end product, which is Foodtech, and that the blockchain is just to facilitate that goal. The code isn’t bad, but there isn’t anything really interesting here. They can code at least.
How long did this code take to write? What other components have they already finished? How far are they with the DAG and Opera Chain? This is one that I may have to update when there’s more to see, as I think they may have a lot more gas in the tank.
No red flags at least, but I was hoping for more.
See the Fantom ICO review here.
Disclaimer: Crypto Briefing code reviews are performed by auditing what is on display in the master branch of the repo’s made available. This was performed as an educational review and any comments in the article are the opinion of the writer. It is normal for code to change rapidly, hence we timestamp our code reviews so that they present a snapshot at a moment in time. Information contained herein should not be used as any comment or advice on the project as a whole.
Fantom Code Review Timestamp: May 8th, 2018 at 14:32 GMT
Share this article
