Lucidity Code Review: Advertising Transparency

Share this article

Even tighter than usual focus on the Lucidity code review, advertising is not an area I know a lot about, so I really can’t comment much on this. The website says it’s “The blockchain advertising protocol for complete data transparency” so I assume there’s some business issue with data transparency in the advertising world that needs solved with a blockchain.

Here it is, “Lucidity verifies marketing analytics on the Ethereum blockchain so the advertising industry can finally transact with trust” and “Digital advertising is broken”. Ok, so someone needs to fix it, I guess.

The team took me through their system, it looks good, they had spent a lot of time and energy on it, and it was a well designed system. Like I say, I don’t know much about advertising systems though, so I was at a bit of a loss.

What I can comfortably say, is that the system is legit, they certainly have the domain knowledge, and it looks like a really good solution, but I’m commenting on something I have very little domain knowledge on.

So I feel that this review is almost unfair, because I’m going to very narrowly focus on their plasma implementation. I love looking at off-chain scaling solutions and I love to investigate how they are implemented and what they actually do. Plasma, especially, I find fascinating because one implementation builds it as side chains, another as blocks on chain, another as transaction store, and each one has its own value adds.

So let’s have a look at how these guys are going about it;

Pity we don’t have the consensus layer yet, and interesting that its a UTXO based implementation.

Actually, before I continue, what is Plasma? No, I’m not leading into a answer, I’m sincerely asking. From what I can understand, it’s building blockchains into a blockchain as a scaling solution? So instead of a transaction, I send blocks (so a root chain block contains a transaction which is a subchain block which contains subchain transactions). And then I ask myself, why? We heard you like blocks in your chain, so we put blocks in your blocks so you can have block block chains? I don’t get it. What is a blockchain? It’s a state consensus engine. A distributed system that reaches consensus on its current state. This is two fold though, this is the blocks and the transactions.

So what do we expect from a plasma implementation? We expect transactions to be checked and validated, we expect blocks to be checked, validated and packaged. If transactions are correct we can assume internal state is correct. So why does it need off-chain consensus if we have on-chain consensus? Same reason we have it on-chain, if anyone can submit a block, then they could submit fraudulent blocks.

So, now I need an off-chain implementation that has nodes, can receive transactions, can validate those transactions, can create blocks, can reach consensus on the blocks, and then submit them to the main chain. So I built another blockchain?

Let’s move on.

Zeppelin MerkeProof and Andreas’ RLP implementation

List of operators, I’m assuming validators. Let’s see.

Header definitions for the chain.

Let’s walk through it, we give the function a header number and some data, we check that the current count of headers is the same as the header number given, we decode the data, we grab the previous header and get a hash from it, we then save it to our header array. Not seeing the transaction validation here, but assuming we have separation.

Transaction structure with inputs and outputs, straight forward Bitcoin UTXO implementation.

Deposit payable (so with Ether) to an address. So this is locking ETH in from the main chain into the plasma chain. We send ETH into the contract, it creates a new transaction output (technically a genesis event), creates the hash, creates a genesis header and then submits this to the subchain.

Withdraw has the proof complexity added in. You need to provide an exit block (state at that block). This is a special exit transaction on the subchain where you send funds to 0x0 (burning them essentially). This is pretty cool.

I don’t see transactions being validated when blocks are submitted from the sub chain and for now it looks like it is just headers being saved and not blocks. I would have changed a few implementation details, but nothing wrong as written.

Lucidity Code Review Conclusion:

I still don’t get Plasma, if you are building your own chain, you have your own chain. I do like Plasma though, and I like this implementation. Good code, well documented, neat and clean. I can’t comment much on their real product and its value add since I don’t know the space well enough. But I do like the chain parts (even if I think they could just build their own chain if they are building Plasma in any case).

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.

Lucidity Code Review Timestamp: June 22nd, 2018 at 17:56 GMT

Share this article