Arweave Code Review for Decentralized Storage
This is the Arweave Code Review, the full on ICO analysis is over here, so I won’t spend too much time today talking about the point of the project or the newness of the team. However I do want to give a passing nod to their claim about decentralized storage, which is pretty bold, to say the least.
“A new data storage blockchain protocol based on a novel proof of access consensus mechanism that creates truly permanent data storage for the first time. Now data is finally permanent, low-cost, and truly censorship free.”
Strong competitors in this space. S3 Glacier Storage $0.004 per GB. IPFS, Ethereum Swarm. Filecoin, Storj. Does data storage need its own blockchain?
And I have a pet peeve here with regards to truly permanent. Nothing is truly permanent, if we pay any attention whatsoever to the Third Law of Thermodynamics, but let’s not get too existential here.
Let’s start with the light paper.
Arweave hash list is the Ethereum light client concept.
Blockhash and Wallet list, nice concepts, let’s break it down. In Bitcoin I need to replay all transactions to get the current unspent output list, I do this, because a block is secure and agreed upon (thanks to consensus), if instead of doing this, I asked a node to simply give me the current balances, it could. Would you trust that node? What if it just gave you a list of whatever it wanted, you could collect multiple lists, and then have consensus on 2/3+1 lists, but given a single list, I probably wouldn’t put too much faith in it.
“The hash of the blockhash list is distributed with every new block”, we need a quick discussion on the longest blockchain and why we trust the longest chain rule. The longest chain is the chain that has the most weight, because it has spent the most energy to get to where it is. We don’t put a lot of faith in the very last block, because it could still be rewritten (not really, we change to a longer chain, but let’s assume rewritten).
So if I just gave you the latest block and told you to trust my blockhash in it, would you? You could definitely trust the list a few blocks deep (dependent on amount of energy/stake spent to reach that depth, 3 in Bitcoin, 30 in Ethereum), but you should probably not put too much faith into the latest block.
“Proof of Access… The ‘recall block’ to incorporate into the next block is chosen by taking the hash of the current block and calculating its modulus with respect to the current block height.”, but why? What value does this add?
Wildfire is a latency ranking system, it favors co-located servers.
Not seeing any data on how storage is done with permanency and low cost?
Let’s jump into code.
PHP, haven’t seen that in many years. Let’s start with the PHP SDK.
Now the storage makes sense, it’s stored directly in the transactions, and thus the blocks, that’s why blockshadow exists, otherwise there will be too much data in each transfer, and forks will increase.
That’s why Proof of Access, since it incentivizes miners to host more blocks (or rather more data storage). Once off, permanent storage, since everything is contained in the entire blockchain, and cheap because I am only paying once to save the data.
The picture makes a lot more sense now, I like it.
Password protection on the key file is probably required.
Good comments, hardcoded $ip.
The SDK is good. Good separation of logic, neat code, well designed. Let’s move on.
Fantastic documentation, good structure, not a fan of the naming standard, but that’s minor. Well written test coverage.
This is really good.
Started working on it in August 2017. I guess I’d have to say my Arweave code review gets a gold star, very impressive how much they have accomplished.
Didn’t find Proof of Access though.
Arweave Code Review Conclusion:
I really like it, turning miners into storage nodes by forcing the consensus layer is sexy. Good, neat code. Well designed and well documented.
In all honestly, I’ll still store my data on IPFS and S3, but if their token is cheap enough, this could be a great storage solution.
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.
Arweave Code Review Timestamp: May 20th, 2018 at 10:44 GMT