LEEP is an up and coming distributed ledger technology (DLT) start-up that is looking to break into the DLT space with a brand new blockchain design concept. LEEP’s proposed blockchain based network architecture is built from the ground up and addresses the glaring scalability issues that plague existing blockchain systems without relying on conventional solutions, which tend to introduce potential security vulnerabilities or significant complexity and, for the most part, remain as topics of research.
In traditional blockchain networks, transactions are packaged into blocks and prioritized by miners/validators based on transaction fees or gas price. In such systems, transactions take place in a sequential manner, where scalability is inhibited by block size/gas limit and the length of time it takes for the entire network to reach consensus. In cases where transaction dependencies exist and the order of events is important, traditional blockchain systems may encounter issues where the network attempts to process transactions out of order, which can lead to transaction failures, i.e. an account attempting to withdraw funds from a wallet address, before funds were made available through deposit.
These scenarios are known to occur in practice and are a result of the fact that miners/validators choose which transactions to pack into a given block, where the decision is generally based on fee amount and block size — as opposed to the time of transaction issuance. Conventional blockchain systems have no built-in failsafe to prevent undesirable scenarios like this from happening. LEEP’s blockchain solution circumvents these issues entirely through use of a radically different approach to validating transactions and committing verified transaction records to the ledger.
Although simplicity is at the core of the Leep network’s design philosophy, it can be difficult to understand without prerequisite knowledge in certain areas of mathematics, namely graph theory. Before touching on some of the advantages that LEEP’s novel network architecture offers over traditional blockchain systems, let’s first introduce the fundamental mathematical property that is instrumental in securing LEEP’s truly scalable network. This property is known as the “Closure” of a graph and the purpose of this article is to explain what it means and how it is applied in LEEP’s DLT network design.
In graph theory, a graph comprises a set of vertices (nodes) and a set of edges (links/arrows), through which the vertices are connected. A directed acyclic graph, or DAG, is a type of graph where all of the edges are associated with a particular direction, i.e. from left to right, and link the set of vertices without forming any directed cycles such that any given vertex can follow a path that leads back to itself. A DAG can be used to model a sequence of events, where the order in which they occur can be identified by following the directed edges. A graph possesses closure if, and only if, no outgoing edge leaves a closed set of connected vertices. Now, what does any of this have to do with LEEP’s DLT network?
In contrast to a traditional blockchain network, transactions that take place within the LEEP can be modelled as a DAG data structure through linking nodes that are involved in related transactions. In order to properly construct a DAG, every wallet address in the network is assigned a “home database node”, which can be represented by a vertex, and transactions between addresses form the directed edges, or arrows, of the DAG. Within the DAG data structure, dependencies between transactions, and the order in which they should occur, are clearly mapped. Moreover, in order for a DAG to be accepted by the network, and ultimately committed to the blockchain transaction record, the LEEP consensus protocol stipulates closure as a requirement.
The network makes an effort to close every DAG by establishing internet connections between all database nodes that comprise the set of vertices in a given DAG, such that each node is informed about and can validate every relevant transaction that makes up a part of the graph.
While a collection of connected database nodes can themselves determine whether or not the DAG they are a part of possesses closure, an additional layer of security exists to prevent the network of database nodes from acting like a trusted system. Instead of relying solely on the database nodes of a given DAG having to reach a consensus on the validity of encapsulated transactions, the network also initiates a reverse look up mechanism to guarantee closure of the graph. This mechanism uses a pseudorandom process to select nodes, which are external to the DAG itself, that serve to query the incoming/outgoing transactions of the wallet addresses involved in the DAG and raise an exception in the event that the property of closure is not satisfied.
Although the requirement of closure may seem trivial, it is the crux of LEEP’s ingenuity as it provides a very elegant and simple solution to the double spend problem — the problem that conventional blockchains solve through inefficient, or insecure/centralized consensus mechanisms. Efforts to double spend tokens will always form an edge that is directed outside of a closed set of connected nodes, and so closure of the DAG is not possible when a malicious actor attempts to double spend tokens. The following example should help to visualize why this is the case.
The above visual considers two scenarios, one in which a DAG is accepted and another, where a DAG is rejected. Vertices A, B, C and D are each database nodes, and a definite sequence of events must exist in order for the transactions to succeed, i.e. transaction Tx2_bc cannot occur until after Tx1_ab as the initial balance in the wallet of node B is insufficient to carry out transaction Tx2_bc. In both cases, a connection is established between nodes A and C, which ensures that node C is informed about transaction Tx1_ab and so the order of events in the directed sequence can be determined by each node in the DAG.
The link that joins A to C forms a closed set between nodes A, B and C. In each scenario, we are looking at a DAG data structure that models multi-party transactions, where transaction dependencies are identified in a natural manner. It should be noted that every transaction shown in the two cases above is issued from a single wallet address from its respective home database node.
Case Where DAG is Accepted
Taking the case where the DAG is accepted, by inspection it is quite obvious that there are no dangling transactions or attempted double spends present and that the DAG possesses the property of closure. The wallets involved in the transactions all start off with a balance of one token each, before the wallet in node A sends 1 token to the address in node B (Tx1_ab), followed by a final transaction of two tokens from B to C (Tx2_bc).When these transactions are initially created by end users of the network, Leep’s Pollen protocol delegates to the database nodes seen in the example, where nodes A & B are assigned the task of broadcasting (Tx1_ab) for consensus and nodes B & C are responsible for validating transaction Tx2_bc.
It is through this process that the link between nodes A and C can be established, which forms a closed set between nodes A, B & C. Since the property of closure is satisfied in this particular occasion, funds have no means of exiting the DAG, i.e. the sum of the initial and final wallet balances are equivalent, and so no exception is thrown by any of the database nodes or by the network during the reverse lookup process.
Case Where DAG is Rejected
Looking at the case where the DAG is rejected, the wallet address assigned to node A attempts to send 1 token to an address in node B (Tx1_ab) while simultaneously double spending this same token through a transaction to a separate address in node D (Tx1D_ad). Similarly, the scenario where the DAG is accepted, a following transaction of 2 tokens from nodes B to C (Tx2_bc) is broadcast to the network. We can consider two possible situations with this double spend attempt.
In one scenario, a specific end user is hoping to cheat the system and is acting in isolation, in which case database node A will immediately identify the fraudulent transaction and will invalidate whichever transaction came second — potentially preventing Tx1_ab from happening, automatically making Tx2_bc invalid due to lack of funds. In this case, Tx1D_ad would be the accepted transaction and no closed set would exist between nodes A, B & C, resulting in the DAG being rejected. In the other scenario, we assume that nodes A, B, C & D are somehow corrupted into accepting invalid transactions and “lying” about the state of closure in the DAG. Reverse Lookup allows us to find the main “address” of the balance and verify that this is a valid transaction. Lookup time under heavy load (100k transactions per second) would still be performed at O(log n). External validation and redundancy is required to triple guarantee safety (No trusted party.)”
Since the state of every wallet address in each database node is a matter of public record (blockchain), the latest confirmed state of every wallet, including all wallet addresses associated with database nodes A through D, can be checked against all transactions broadcast for consensus in the network and validated externally. As part of this check, the sum of the initial balances minus the final relevant wallet balances will not be equivalent, showing evidence of funds having escaped the DAG through a break in closure. As the external validators are chosen through a pseudorandom selection process, there is no feasible way to orchestrate a targeted validator attack that would allow for a double spend to go undetected and therefore the requirement of closure prevents this type of malicious behaviour from ever being accepted by the network.
Benefits of LEEP’s DAG Closure
The use of a DAG data structure has obvious benefits when it comes to transaction dependencies and cases where the ordering of events is imperative. This can be put down to superior consistency characteristics in Leep’s network architecture versus eventual consistency, which is what we see in traditional blockchain implementations. LEEP will not process transactions unless all related transaction dependencies can also be validated so no transactions are ever reversed in the event of possible network attacks and the correct order of execution is always assured.
Since only a relatively small portion of the network needs to be involved in the validation of transactions that make up a part of any given DAG, the rest of the network is free to validate separate DAG transactions. This is one of the major innovations of LEEP’s architecture. Similarly to the concept of sharding, transactions can be processed throughout independent network segments simultaneously, which delivers a truly scalable solution where the total network transaction throughput is proportional to the size of the network. The bigger the network — the greater the network effect, as a larger number of nodes increases the amount of concurrent transaction processing and allows for a higher degree of parallelism.
Unlike sharding however, LEEP achieves scalability through use of a network that is made secure through the mathematical property of closure. The main challenge with sharding is security. The communication between shards and the security of a single shard is weak. As more shards are introduced, the security of sharding goes down. A 51% attack against Ethereum would only require 12.1% of the mining capacity to perform a similar attack after 4 shards are created. DAG with closure and reverse lookup ensures the overall state of the network is made available to every node in a reliable, fast and consistent manner.
By stipulating closure as a requirement, LEEP does not derive its security from hashing power (PoW) or the number of tokens that are held by individual node holders (PoS), but through the consensus protocol’s unique implementation. Another major advantage of this approach includes immunity to majority network attacks (33% and 51%) as consensus is not reliant on the entities influence within the network. Since pseudorandom verifications are also involved in the validation of transactions, targeted denial of service (DoS) attacks are also mitigated. Attack vectors such as DoS are further alleviated through use of dynamic node roles within the LEEP but this is beyond the scope of this discussion.
While many of today’s blockchain companies are focused on achieving scalable networks by building solutions on top of existing architectures, LEEP is building its system from the ground up (with scalability in mind!) and plan on challenging all competing solutions with its proveably secure, closure-based DAG consensus mechanism.
LEEP collects, delivers and processes trustless data to facilitate a deep data economy with smart contracts and connected big data. Its unique and elegant network design sets the standard for efficient and purposeful
LEEP is a scalable, secure, ACID-compliant Smart Contract platform for Sustainable Business. Our truly unique approach and implementations of various technologies have led us to the creation of a network infrastructure that actually works for business, while blockchain technologies thus far have had limitations and impediments.
LEEP has focused on the pitfalls that stand in the way of mass adoption of this technology, and we provide a platform that is flexible for integration and 100% Solidity compatible, with upgradable smart contracts and fortified security. We encourage, aid, and support the development of feasible software solutions that address issues that intend to improve the global ecology and the human experience.
LEEP: The Necessary Blockchain Infrastructure for Business and Sustainability