Stegos Code Review: Privacy Platform For Decentralized Mobile dApps

Stegos is a completely private, confidential, and scalable cryptocurrency that’s friendly to the environment.

At this point I’m tempted to say these guys are OG in this space. Feels like I’ve known Joel for years, and definitely one of the most persistent guys I know.

Remember that whole gen 1 vs gen 2 vs gen N argument that was big last year? Some chains claiming to be gen 8 or whatever, I think we are finally seeing the gen 2 wave. We are seeing a lot of PoS + BFT + privacy protocols coming out, and more and more of them are reaching maturity. I previously reviewed Harmony, I’m currently looking into Elrond, we have CasperLabs, Near, Aleph and quite a few others coming out, and I would say they all fit this gen 2 narrative.

Technologically, this is good to see, it means the tech stack is maturing. I’m not sure if it means anything more than that, but let’s see.

So Stegos. Platform for privacy applications. Stegos provides an absolutely private and secure foundation for building decentralized mobile apps.

The usual gen 2 101 promises. Absolute privacy, sharding + high tps, low finality (seconds), data pruning, runs on a mobile device, etc etc. “A secure mobile VM for running HTML/CSS/JavaScript apps” is interesting though.

High level promises, check, let’s get into the whitepaper detail.

Snowball is definitely interesting. Will need to dive into it. But let’s do a quick high level primer on blockchain and determinism. Why do we trust a bitcoin or ethereum balance? Because we can track every transaction from 0 with basic arithmetic. I know an account has a balance of 10, because it received an input of 10 and I can trace that input all the way back to genesis (or a block reward — since only genesis and block rewards can create new outputs).

What happens if these unlinkable and private? How do I know that the value I see I can trust? Original privacy was just about not being able to really see where a transaction went, sort of similar to what exchanges do, you have a bunch of inputs, trading happens in the middle so the inputs are completely messed up, and your ouputs could be from anywhere.

To give a more concrete example. Let’s say I deposited 1 ETH, traded a bit and made 2 ETH, and now I withdraw 2 ETH. That 2 ETH is no longer connected with the 1 ETH I deposited. This is essentially a privacy transaction (although getting access to the exchange audit log (assuming they keep one) can give me this data). Some clever cryptography (like ring signatures) allow this, some insane cryptography (like bulletproofs) perfect this.

So a ring signature can make the input and output hidden. What about value? I want to send you 10, but I don’t want anyone to see I sent you 10. This is where rangeproofs come in, a rangeproof provides a proof that a value is within a range, without exposing the actual value. So the rangeproof would prove that the value is greater than 8 but less than 12 (for example).

So now I can mix up the from/to and I can hide the value, but what if I still wanted to avoid the “to” address, I think I first saw this in Wanchain with their OTA transactions. Essentially another hidden address connected to your primary address that you could transfer to. This would add the balance to your primary address, but transfers would show up to your secondary address. This is stealth addresses.

So a lot of different techniques to be able to accomplish some pretty cool privacy behavior. So curious to see how Snowball does it.

Need more data on their compacting. Looks like they remove spent outputs and only keep the unspent values (sort of like mimblewimble compacting).

Good paper by the way, at some points not technical enough for my liking, but very good at explaining the high level concepts. I take that back, reading the addendum provides all the technical details I wanted.

Ok, so definitely a mix of everything we have seen so far, Pedersen commits, bulletproofs, address cloaking, encrypted payloads, utxo pruning, PoS, pBFT, value shuffle and mixing. It comes across very elegant though. Quite often I read these papers and it seems like someone just copy pasted different sections from other papers, this one flows very logical with each additional choice being added seemingly thought out and not simply added for the sake of being able to say they have it.

Reading the paper actually makes me excited to look at the code. So let’s do just that;

 

 

Let’s do the basics. 871 commits, 12 branches, 6 releases, 6 contributors. Healthy repo. Good issue and Pull request management.

 

 

Consistent and good contributions shared across the top 3 contributors. Very nice to see and shows a healthy code base.

Rust codebase. Seeing this more and more often, seems the days of golang are shifting.

 

 

API is a straight forward websocket implementation;

 

 

No need to go to deep into this, good architectural design.

 

 

Blockchain looks promising.

 

 

A chain versioning number, I don’t see that very often. I like it.

VRF for leader. (I can’t see VRF without expecting BLS, nasty habit)

 

 

Rust is really just such an elegant language. Code in it always looks so pretty. And I say that as a coder that isn’t really a big fan of rust…

 

 

There is our BLS friends. Ok, so leader election proved with VRF and BLS signatures collected for block. pBFT consensus 101

 

 

Ok, so it looks like a bunch of transactions are taken in a given block (for different input/output pairs). These are then randomly sorted (based on the hash, but hash is random) and then outputs are assigned. This is very simplistic, yet very elegant. So to provide a bit more of an example, let’s say you have;

inputOne (value 10) outputOne (value 10)
inputTwo (value 7) outputTwo (value 4) & outputThree (value 3)

In Bitcoin, we would see two transactions in the block, tx1 with inputOne and outputOne and tx2 with inputTwo and outputTwo & Three. Here Stegos creates the super transaction, by abstracting the transaction layer. So instead they would simply have supertransaction;

input (value 10)
input (value 7)

output (value 3)
output (value 4)
output (value 10)

Add in the random ordering (from that hash) and you essentially can’t map any of the inputs to their outputs.

Again, very simply, but very elegant.

 

 

Good code is not complex code. If you can take complex ideas, and make this easy to read, and comprehend, then you know what you are doing. This is good code.

 

 

Leader election, using random pbc::VRF, we need to go look at stegos_crypto::pbc.

 

 

Escrow management for stake. Something simplistic, but I didn’t think about it. Nice touch.

Merkle code is good, multisig code is good. Nothing specific to extrapolate on them, I enjoy going through it, but no secret sauce to mention.

 

 

Looks like all the fun stuff is in stegos_crypto, will get there soon enough;

 

 

Default is private, you can still do public though;

 

Again, very simplistic techniques being used, but combined so elegantly to flow into really great code.

 

Stealth key generation, deterministic random within a range. They thought of a lot of potential attack vectors. This team is well versed in cryptography. The whole output.rs file is really great.

 

 

So here we already know we will have a stealth address, bulletproof for amount, and that these transactions will be bundled up into one big super transaction to mix the inputs and outputs. Everything they said they would do based on the whitepaper. The pBFT/BLS/VRF covers leader selection + sub minute finality with potentially greater than 100’s of transactions per second.

Lots of checks and balances and thought that went into potential attack vectors.

 

 

Just look at that, I love that validation checklist.

 

 

Consensus is 155 lines of code, not a measurement, just elegant.

 

 

Variable fast (less secure) or secure (slower) variations on their pbc which uses Ben Lynn’s PBClib. It’s solid.

Their crypto libraries are better than their blockchain libraries…

 

 

Networking is solid, pubsub and Kademlia.

Stegos Code Review Conclusion:

It’s really good, given how persistently Joel has been annoying me in telegram about doing a review I actually hoped it would be bad. But it’s really good.

All the promises (VM excluded) are here, so I’m not quite sure why they aren’t at mainnet yet? I’ll be adding them into the list as a strong contender for the gen 2 candidates. Looks like a solid pBFT + privacy + PoS + compacting blockchain implementation. I look forward to testing out the mainnet.

 

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.

Stegos Code Review Timestamp: May 21st, 2019

 

The post Stegos Code Review: Privacy Platform For Decentralized Mobile dApps appeared first on Crypto Briefing.