GEO Protocol Code Review: Internet of Value

Share this article

It’s definitely odd that no matter how serious the whitepaper… no matter how much the font choice wants to look serious and bookish… no matter how the design is led by geometric shapes and single colors… even the most reserved projects just can’t help the hyperbole sometimes.

Even GEO Protocol is not immune, and their website is all of the above.

Infinitely scalable… I’m going to start taking a shot everytime I read that term.

Don’t worry, they make it up for it in lots of other ways.

“Decentralized p2p protocol for values exchange”

“Creating a universal ecosystem for value transfer networks.”

“GEO Protocol is an open-source base layer protocol for cost-efficient, lightweight and infinitely scalable value transfer, merging blockchain and traditional finance worlds together.”

“Local consensus and absence of common ledger let GEO overcome throughput, speed and cost limitations that the blockchain industry is currently facing.” — I do like local consensus and absence of common ledgers. That is essentially the bottleneck

“Nodes create the network map where the neighboring nodes and channels between them, as well as existing assets sending/receiving limits for these channels, are placed.”

“The algorithm builds a route that shows what sums and to what nodes could be transferred and to what nodes in order to perform the payment with minimal cost.”

They definitely have my attention. I need a whitepaper.

This is some weird layer 2 layer 1 hybrid protocol. Kind of state channel meets blockchain.

So when I want to transfer value from A to B, it creates a route to travel from my node to your node, and the participants in this route do the consensus. Definitely need to unpack this more still.

Complex design, but it makes sense, Nodes agree on one thing, transfer, nothing more, if both agree to transfer a value (I am willing to send, and you are willing to receive) the transfer engages. They need to confirm with State Keepers on the validity of the value transfer. Need to go deeper into state keepers to see how they maintain state without impacting performance.

Here I’m not understanding something, Nodes participate in the transfer, so does each node store a specific account balance? So only node #24 has my account, and node #126 has yours, so node #24 has to talk to node #126 for balance transfer, and they might not have a direct line so node #24 has to ask node #58 to ask node #126, then consensus happens between #24, #58, and #126. How can they then form consensus if only node #24 knows the balance? I need to understand where the account and the balance lives to understand the local consensus better.

“Equivalents list is stored on a separate Ethereum contract” does Ethereum act as a custodian here?

“Through GEO, Alice (side A) and Bob (side B) form a multisig transaction to open the multisig address in the blockchain.”. So the actual value transfer happens on the chain itself, so this is essentially an escrow transfer on-chain. Ok, that’s nice, but kind of boring since it’s just a utility wrapper. Let’s look at trustlines instead.

Trustlines is data transfer.

Ok, so not seeing the infinitely scalable here. Not seeing how this is double-spending proof. Especially if I use two different coordinators and routes, or where the balances are stored for validation. So let’s jump into the code;

GNS (Geo Name Service), Observer, and Network client. We are interested in Network client;

C++, good commits and branches + contributors.

Libraries used, json and sqlite3

Very busy core repo. We care about, Core, trust_lines, transactions, maybe topology, payments/reservations? equivalents? contractors? cycles? Some interesting repo’s. Let’s dig in.

Nice abstraction and encapsulation. Haven’t seen proper identifier use in quite awhile.

Start -> init systems (stuff like load config json) -> write PID (for process monitoring -> beginAcceptMessages & Commands (the IO work loop)

Really great code layout.

Very neat, well designed. Good checks and balances as well as error handling. Seems like very safe code.

Very good code so far. This is a routing system moreso than a ledger, I feel you still need an underlying ledger to really do anything with this (or some centralized balance entity), so you always have the slowness of the underlying system. This is closer to a cross-chain abstraction interface than anything else.

Part of route algorithm to see if there are enough balances.

Path checking.

GEO Protocol Code Review Conclusion:

This is a distributed data transfer protocol. It allows users to semi agnostically and in a distributed fashion do escrow transfers for on-chain or other custodian assets.

It’s good code, from a code design, implementation, architecture, and abstraction perspective. I’m left with a bit of a “but why?” feeling, although I’m a base layer guy so I never 100% grasp these interface layer protocols. This is akin to a fully disconnected airswap or something similar where you control the interface portion as well.

Could be an interesting layer to use, I just don’t currently see the use case.

You can chat about GEO Protocol in our Telegram group.

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.

GEO Protocol Code Review Timestamp: April 20th, 2019

Share this article