Republic Protocol Code Review: Dark Pools

Share this article

Republic Protocol and its dark pools aim to facilitate transactions on a hidden order book. There are clear benefits for high profile individuals, whales or anyone else interested in transferring funds to another party without the transfer being publicly available. The network is maintained using Republic Darknodes. The Darknodes accept the trade requests, match the transactions and facilitate the release of digital assets, without exposing the transactions.

Dark Pools — what are they, what do they do? “Dark pools are private exchanges where financial assets and instruments are traded and matched by an engine running on a hidden order book.” — Republic Whitepaper.

There are quite a few repositories. So let’s get started.

The first thing I am going to run through from their repository is the whitepaper:

They describe the basics of what they want to achieve, a short description of how they are planning on achieving it, security requirements and the purpose of the token in the ecosystem. Pretty industry standard stuff.

Let’s hop into the code to see how they are getting on.

The code does exactly what the documentation says. It is a library of functions that assist with parallel processing.

Quality code documentation and comments, good tests written for it, but nothing too fascinating happening in here.

The repository hasn’t been touched in the past 4 months. Which is understandable for a repo what it wants to achieve. It’s a generic “import commonly used functions” repo.

The purpose of this repository is pretty simple. It allows for cross-chain transfers between ERC20 tokens, Ether and Bitcoin *Interested to see how the Bitcoin transfer will be tackled.

No real commits in the past 4 months. So I’d assume here is some production ready code in here.

contracts/AtomicSwapERC20.sol

The quality code documentation/comments that we saw in go-do have dwindled down to a minimum. There are couple of basic comments in-between lines of code and a TODO.

I am not the largest fan of overly documented code, but the basic function purpose and parameter description goes a long way towards understanding what is happening in the code.

checkSecretKey doesn’t actually “check” anything, it just does a “getSecretKey” based on the _swapID. It’s just a pedantic function naming issue. Nothing wrong with what the code does.

The rest of the AtomicSwap*.sol contracts in the repository all look the same and have similar functionality. They just use the different transfer mechanism, based on the coin type:

vs.

I was interested to see how they were going to implement the Transfer X to Bitcoin functionality. The README.md documentation just says use the AtomicSwapEther or AtomicSwapERC20 contract together with an external “Bitcoin Script” which will handle the Bitcoin Transfer. When a specific rule set is hit (in this case, a function call), they funds are released. So it is just a normal route.

The README.md is a bit out of date. There is no MinerRegistry or OrderBook smart contract. So I guess we will need to figure out what is going on in the files.

RenLedger.sol seems to be the OrderBook. DarknodeRegistry.sol is the MinerRegiststry. So it’s all there, just the README.md that’s out of date.

contracts/RepublicToken.sol
The ERC20 token (REN). Lots of boilerplate, but nothing interesting. Standard ERC20 contract with a couple of common contract patterns included (Burnable, Ownable, StandardToken, etc.)

contracts/*.sol
Good function and parameter documentation. Neat and well-structured code. The contract code is simple and easy to read.
Overall, the separation is good between the different contracts. I like it.

Hopefully we are getting into the more meaty code now.

7 Contributors, 3.8k commits. This is where the majority of their time and effort has been spent.

At a first glance this doesn’t seem to be a straight go-ethereum clone where they rename every variable. However, if we look in the vendor/github.com/ethereum/go-ethereum we find the standard Ethereum code. Perhaps they have wrapped and used only the functionality that they need?

I would have liked to see a substantial README.md giving an overview of the project, but it is pretty bare bones.

Fortunately, going into docs/docs we come across quite a lot of documentation for the project. There is still no “This is what we are achieving here” though. I stumbled on a nice overview of their Architecture and design principles. It’s good to see the considerations they put in place for how they wanted things to run.

There is lots of code, lots of effort and lots to review. I’m going to just skim over a couple of folders to save time.

Let’s start with the blockchain folder. They have built this current implementation on Ethereum, so it makes sense to only see the Ethereum platform. Republic said that they are blockchain agnostic, so it could be migrated to other platforms in the future.
What follows are a few libraries that interact with the Ethereum smart contract ecosystem defined in the republic-sol repository.
dnr -> DarknodeRegistry.sol
ledger -> RenLedger.sol
rewards -> a reward contract that seems to distributes proof rewards. I’m unable to find the smart contract in their repository though.
accounts -> I am unable to find the contract for this as well.

cal -> contains a bunch of interfaces. I’m very impressed with the amount of effort put into commenting.

I’m going to skip over writing about some of the content. Otherwise this article is going to become really laborious. The code is just good!

identity -> encoding and decoding addresses and multiAddresses. Yay, something incorrect in their comments — or their code?

levelDB -> they are using Google’s LevelDB for a local data storage solution of the orders, order fragments and computations. Pretty much the standard in blockchain.

ome -> the Order Matching Engine! Lots gets kicked off in here. In short, it manages everything regarding order matching. The OME syncs the order book from the renLedger and inserts the change into the ranker. The ranker consumes the orders and produces computations that are prioritised based on a couple of factors.
Based on the computation’s state, it will perform the next action required. First the computation will go through the process of finding a matching pair of buy and sell orders. Once the match is found, the computation is moved onto the next phase.
Computations that have been matched will then be moved onto a confirmed state and it will be stored by the settler. It uses Shamir shares and SMPC mentioned below to join the match.
Again, great documentation which makes the code easy to follow.

shamir -> a secret sharing library. It breaks the secret into smaller pieces (Shares). It can reconstruct the share from a predefined smaller number of Shares than the full number of pieces.

smpc ->an interface for a secure multi-party computer. It asynchronously consumes computations instructions and produces results. Joins the Shamir Shares and send a message to the other nodes notifying them of the join.

And that’s that. Those are the tasty parts of the meat!

In the code for republic-go, we have well documented function calls. There are comprehensive tests written for the majority of the files. All the functionality seems to be really well separated by what they mean to achieve. Comments are regular and very descriptive. I can’t really complain.

Testnet
Republic announced their testnet release on the 18th of June 2018. ( https://bit.ly/2MbtaIS). I head on over to their testnet exchange and everything seemed to be in working order. They have support for MetaMask, Ledger and a Keystore file, with Trezor and Private key support coming soon.
There were some responsiveness issues when working on a smaller screen. No mobile consideration in the designs of the website. So their front end could definitely use some work, but with no publicly available repository for it, I can’t comment any further.

Republic Protocol  Code Review conclusion:

The overall code structure is good. Majority of the code is well written, well thought out and well documented. I’m actually impressed by how well this is coded.

In the rush of the crypto world, it is easy to just get the project out before the deadlines without the documentation and structure maintained in this project. But they stuck to their guns. These developers know what they are doing.

In terms of their mission, they are well on track. At the end of Q2 2018, they aimed to have Atomic Swaps, Ren ERC20 Token, PTP network, Registrar and Order Book smart contract, Secret Sharing, Trader Terminal and their official Republic nodes out. All the pieces of the ecosystem seem to be in place, so it will be interesting to see what the community feedback regarding the testnet will be. They have achieved a lot in the past six months. I look forward to seeing what this project can produce in the next six.

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.

Republic Protocol Review Timestamp: June 21st, 2018 at 14:33 GMT

Share this article