A Complete Overview of the Lamden Suite
EDITOR NOTE (August 28, 2020)- The following overview contains some outdated information that will be clarified at a later date. In the meantime, read this overview with the understanding that some of the fundamentals may have changed in the design and development process of the system.
Introduction
Unlike web application development, the blockchain development resource landscape is sparse. There are uncountable numbers of libraries, tutorials, and frameworks for people to speed up the development time of web applications. The main reason for this is the maturity of web technology. There has simply been more time to develop the tools, which we now use to power the web. Such time has yet to occur the blockchain world.
Furthermore, it’s extremely hard to develop tools for building blockchain applications when we have not seen many examples of how blockchain is used in an enterprise setting. The reason for this is a ‘Catch 22’ situation. People generally are cost averse; they will put time in learning something if the time it takes to learn is short enough. A lot of development tools speed up the time it takes to learn. However, crypto is in a funny position because those tools don’t exist, so even less people actually spend and sacrifice the time it takes to learn how to develop blockchain technology. As more tools are developed, we can expect to see more adoption of the technology. The adoption rate is exponential with the introduction of tools.
Lamden is focused at being the first end-to-end development suite for blockchain applications. We do not focus specifically on smart contracts on a pre-existing system, but rather creating new and custom blockchains and decentralized systems that are not encompassed within the application space of smart contracts. Those who know a thing or two about smart contracts know that there is a limited subset of what they can do. The tools that Lamden is making supersede that subset and expose a development environment wherein any type of decentralized application can be developed.
This could be as explicit as a blockchain that we are all familiar with or as detached as a social media application, where people are storing and sharing information that is dear to them and owning that data on their own personal server. This type of application cannot be developed on top of existing blockchain platforms due to extreme costs and rigidness of the systems.
The Rationale for a New Blockchain
Making a blockchain from scratch is no simple task. In fact, Bitcoin, Litecoin, ZCash, and Dash all share 90% of the same code for this very reason. What makes them different are very minor differences between hashing algorithms and transaction processing. Ethereum is a unique code base. We are just now seeing forks of the Ethereum code into new projects, which are pitching themselves as unique, such as Wanchain, Ubiq, and Tomochain. However, much like Litecoin and ZCash, these projects make use of 90% of the Ethereum code and thus inherit 90% of the same problems.
We did not want to inherit the same problems that Bitcoin and Ethereum have. The first and foremost problem is having transaction fees.
Instead, we wanted to push the anti-spam mechanism of proof of work outwards on the client side. This is a similar system to Nano and IOTA. By having the client do some work before sending a transaction, you prevent spamming of the network and can support transactions without any fees.
A common misconception of blockchain is that a single transaction is hard to compute. This is not true. A transaction only costs a certain amount of cryptocurrency because those fees pay for the proof of work that miners have to do to solve a block. If proof of work is removed from a system, the requirement for transaction fees is diminished. You can see proof of this in classical payment systems such as PayPal and Stripe, which charge transaction fees as a stream of revenue, not a means to support the network. Processing transactions at these scales are magnitudes less difficult than solving a single block on the Bitcoin network.
Thus, we want to remove both proof of work while providing free transactions. Each proof that a user adds to their transaction takes between 500 milliseconds to 1 second. This prevents system spamming. A transaction is not processed unless a proof is valid. The transaction is then quickly processed in blocks of 1 second or 10,000 transactions, whichever comes first.
Blocks are processed without proof of work by means of delegated proof of stake. Members of a network elect delegates to mint blocks together. The blocks with the most confirmations are committed to the blockchain. This system has been demonstrated as robust on the BitShares network.
Associated with development, we noticed that every blockchain out there was written with no intentions of modification. There is no easy way to add a new feature to Bitcoin or Ethereum without rewriting the core code. This is primarily because the developers of Bitcoin and Ethereum did not write the software to be modified, but with the intent of everyone using their distribution. This assumption is flawed. No system will ever capture 100% of the market. Many unique parties have unique needs that they can address with a development kit that allows for modification and deployment of their own software. Lamden’s blockchain supports a fully custom smart contracting language in Python as well as modular components that allow developers to make their own node types, rules, and transaction types.
For example, a developer can not only create a system with some Lamden smart contracts out of the box but can also create new classes of participants that are unique to their system. Take the social media example into account again: the nodes could be content producers, content consumers, and advertisers. No blockchain system in existence has the ability to support mutation of the nodes on their network to allow for this. The amount of custom development that would go into creating these unique players would be similar to developing an entirely new blockchain from scratch because it’s so fundamentally different than how blockchains are currently written.
However, Lamden sees these types of applications being developed in the future and thus is providing the interface to create them. Developers can create nodes that have any type of properties and responsibilities in the system. Allowing this type of creativity is extremely important to the project and justifies the case for a custom blockchain.
Finally, the introduction of this new modular blockchain fits perfectly into the original vision of providing statically defined development tools as laid out in the original whitepaper. Instead of just producing a blockchain out of the box and installing smart contracts on it, you can now create an entire blockchain project, develop and tune all aspects of how people interact and interface with the system, install and develop new smart contracts on it and deploy it abroad, all within a cohesive development environment.
A Recap of the Original Vision
Lamden was originally a suite of three tools that each addressed a specific need in the development process. Now, with the introduction of Cilantro, the modular blockchain, four total tools are being developed: Saffron, a project automation tool; Flora, a smart contract repository system; and Clove, an atomic swap automation tool that connects blockchains together (Cilantro being the fourth).
Saffron
Most software development tools have some way to generate the project scaffolding automatically. This scaffolding is the code that is required to get the application up to a point where you want to start customizing it. While this sounds like it may be too prepackaged for developers, it is actually the opposite. In the example of mobile application development, the project scaffolding that is built automatically generates all of the low level implementations for running the app on the phone’s hardware so that the programmer can focus on the specific features of their application, how it looks, and how it interfaces with other systems such as online databases.
A lot of project scaffolding is done automatically in today’s development pipelines and for many programmers is completely out of view of what they are developing. Another great example of this is the Node Package Manager for the Node.js system. This software initializes a ‘blank’ project for you to start developing a Node.js program. However, it also includes code for uploading it to the Package Manager once you are done and makes it very easy to import in new code. The programmer of these projects does not focus on the integration with the package manager service. This is setup automatically by the tool at the beginning of the project’s life.
However, as you may have guessed, such a system does not exist for blockchain applications. Part of this is because of how new the technology is. Another assumption can be made that the current blockchain platforms are simply not designed for developers in mind because they were made to be a singular and universal implementation of the tech, as was discussed before.
Regardless of the reasons, the need is still very strong for software that automates the ‘dirty work’ of getting a blockchain project off the ground. This is the aim of Saffron.
Originally, Saffron was simply a tool to generate new Ethereum-based networks. However, now that Lamden is producing its own blockchain, the concept of Saffron has evolved slightly. Saffron is still an automation tool for deploying ‘empty’ networks. However, there are some stronger optimizations with the Cilantro blockchain that have not been previously discussed.
To reiterate the original vision, Lamden sees a blockchain as a data store that people all agree upon. In the case of Bitcoin, the data stores transactions. For Ethereum, it can be anything. We see a lot of tokens being created on the platform as well as non-fungible items such as CryptoKitties and CryptoPunks.
With this concept in mind, we are positioning Saffron as an easy way to create a blank data store that uses blockchain. The underlying technology that powers this data store is up to the developer to choose. They may like the UTXO model that Bitcoin-based blockchains provide. They may prefer the ‘global state’ paradigm that Ethereum boasts.
Regardless of the decisions of the developer, Saffron is capable of generating a blank blockchain of that technology on a computer or cloud instance to allow development to occur inside of it. A lot of existing systems add an additional layer on top of Bitcoin (see Omni, Rootstock, and Counterparty). These systems are generally developing Bitcoin Scripts, a proto-smart contracting programming language, to extend the capabilities of the UTXO model. An enterprise or developer may want to do this for their own internal purposes, and so deploying a Bitcoin instance with Saffron on their internal infrastructure and being able to interact with it using the Lamden tools would be very important to them. Similar use cases exist for Ethereum. Saffron extends itself into chains with completely different underlying architecture as well. These include Monero / Cryptonote systems, NXT, NEM, EOS, NEO, etc. Developers can also deploy a Bitcoin-code fork such as Dash or ZCash as a starting point.
For Cilantro, Saffron exposes a much larger customizability space. What project scaffolding tools generally do is set up the folder structure and ubiquitous code that does not have to be changed or rewritten. Because Cilantro is programmed to be modular, the blockchain is ultimately a collection of code in a folder structure. Some of this code does not change, such as the routing of messages throughout the network and how blocks are produced and verified with Merkle trees. Most developers don’t want to modify this. They are more interested in the logic that occurs when certain transactions are sent in the network and how nodes behave. That’s why these two structures are developed abstractly. They can be modified, created, and added to the project directory without any additional installation and are then dynamically loaded when the software is run. This allows extraordinarily fast prototyping and development because programmers don’t need to deploy code to a testnet or set up special software such as TestRPC to emulate the environment in which the new code is being executed. Everything is included out of the box.
Flora
These concepts naturally allude to Flora, the smart contract package manager Lamden is developing. Not only is a lot of code similar that project scaffolding generates for the developer, but a lot of code can also be shared with other developers as it solves a very common problem. This is the entire idea behind open source software and package management. Rather than rewriting code from scratch each time, we use a package manager to find code that other developers have already made and open sourced. This makes our development time much faster. It also leads to better code. Because the packages are open source, the community can suggest improvements and fixes. Open source software is often times seen as more secure because if there are fundamental problems with it, those problems will be exploited early on and exposed to the original developers who will be forced to patch it.
The idea of blockchain security though package management is two-fold. Smart contracts control massive amounts of funds, and so it is even more important that they have no bugs and are legitimate. Smart contracts that are open source can be put through a community security audit to find above ground bugs. For smart contracts that get professional security audits, like the ones that OpenZeppelin develops, it’s very important to get the exact code that had the security audit. An alteration of the code done by a community member to add additional functionality or improvements could introduce new bugs. At worst, a malicious developer could create a version of a smart contract that has an intentional exploit that they want to take advantage of later. Once that new forked contract from the package manager is installed and the new code is deployed, the malicious developer can expose the exploit and compromise the smart contract. This is obviously something that needs to be avoided.
In the current smart contract landscape, there is no de facto standard for package management. The method by which to find and download smart contracts exists via browsing GitHub, a general code repository site. This method does not support dependencies, versioning, or the security that a good package manager needs. It is also not a scalable solution because it is not easily automated.
Furthermore, the lack of a true dependency manager stifles innovation. In other coding environments, people can import code and build on top of it extremely easily. This new code then gets packaged into a new and more complex library which then gets imported by another person’s project. As this process repeats itself over and over again, more and more complex code gets developed leading to a very mature field of libraries and frameworks. Such an environment does not exist for the smart contracting world and is one of the reasons why development in the area seems slow and stifled.
Thus, the best implementation of a smart contract package manager couples the convenience and practicality of a conventional package manager with the security measures seen in the blockchain space. This is why Flora features a private-public key pair system where packages have to be signed with a wallet key. This wallet key identifies the developer of that code and uploads it to the network in a directory made specifically for that key.
Therefore, each package and piece of code uploaded is cryptographically verified by the signature provided that the developer that claims to have uploaded the code has, in fact, written said code. This prevents people from passing potentially malicious code off as the real thing.
While Flora was originally envisioned for Solidity and Ethereum smart contracts specifically, with the introduction of Cilantro, it also serves as a repository for all of the smart contracts that people create for the Lamden tools. Furthermore, as more and more systems support smart contracts, such as NEO, EOS, and Lisk, we can expect to easily integrate them into the platform as well. Even Bitcoin Scripts can be added to the Flora database, whether they be in raw byte code format or higher level Ivy code that is being developed by Chain.
Another thing that Lamden has identified in smart contracts is that a lot of them are very similar to one another. Whereas Python packages differ from each other very fundamentally, most smart contracts are associated with keeping a ledger or track of ownership of digital things. Thus, we believe that a lot of the code itself can be reused and some people just want to modify minor details of a smart contract rather than import it and then write a new smart contract around it, which is how standard programming packages are treated.
We’ve introduced a library called ‘tsol’ which stands for Templated Solidity. In this library, a meta smart contract can be made to allow specific variables to be defined at a later date. This is important for things such as creating new ERC20 tokens when you really just want to modify the name, decimal point precision, and total supply. This will allow an even lower barrier of entry for programmers who want to develop their own smart contracts because custom smart contracts can be developed with a single JSON payload.
The ‘tsol’ format can be ported to any smart contracting language and its abilities to describe meta contracts in other languages is currently being explored.
pragma solidity ^0.4.14;
contract Table {
address owner;
function Table() {
owner = msg.sender;
}
struct Model {
{% for key, value in struct.items() %}
{{ value }} {{ key }};
{% endfor %}
}
mapping (uint => Model) lookup;
modifier onlyOwner() {
require(msg.sender == owner);
_;
}
function get(uint id) internal returns (Model bb) {
return lookup[id];
}
function set(Model b, uint id) onlyOwner internal returns (Model bb){
lookup[id] = b;
return lookup[id];
}
{% for key, value in struct.items() %}
function get_{{ key }}(uint id) returns ({{ value }} a) {
Model m = lookup[id];
return m.{{ key }};
}
{% endfor %}
}Example tsol code. This concept can be ported to any other programming language (including our own, Seneca!)
{
'contract_name' : 'Book',
'struct' : {
'title' : 'string',
'author' : 'string',
'owner' : 'address'
}
}All the data required to create a brand new smart contract that behaves like a database table. Below is the output.
pragma solidity ^0.4.14;
contract Table {
address owner;
function Table() {
owner = msg.sender;
}
struct Model {
string author;
string title;
address owner;
}
mapping (uint => Model) lookup;
modifier onlyOwner() {
require(msg.sender == owner);
_;
}
function get(uint id) internal returns (Model bb) {
return lookup[id];
}
function set(Model b, uint id) onlyOwner internal returns (Model bb){
lookup[id] = b;
return lookup[id];
}
function get_author(uint id) returns (string a) {
Model memory m = lookup[id];
return m.author;
}
function get_title(uint id) returns (string a) {
Model memory m = lookup[id];
return m.title;
}
function get_owner(uint id) returns (address a) {
Model memory m = lookup[id];
return m.owner;
}
}Clove
The most compelling piece of the original Lamden ecosystem was Clove. Clove makes the process of constructing and participating in atomic swaps automatic and easy. For those who are unaware, atomic swaps are a special type of smart contract that allows two people who do not know each other well enough to trust one another to exchange assets on completely different blockchains. This will lead to the rise of peer-to-peer exchange of cryptocurrencies as well as the exchange of other types of objects or assets peer-to-peer. It’s easy to imagine real estate ownership rights being exchanged in this manner rather than going through a centralized exchange because each house on the market is completely unique and being sold by a different real estate agent.
The details of an atomic swap are as follows: a random piece of data is generated and placed into a smart contract that states ‘if the hash of this random data is sent to this smart contract from the correct person, send the coins being sent to this smart contract right now to that person.’ What this means explicitly is that the smart contract is created without actually using the secret. Because the hash of a piece of data is deterministic and irreversible, the originator of this first smart contract can share the hash with the person they want to trade with without exposing the secret prematurely.
Thus, the originator shares this hash and their transaction with the other party. Said party can see if this person has in fact set up the transaction correctly because the blockchain is open. If the person has not set the transaction up correctly, the party can simply not follow through with setting up their side of the transaction. This would just cause the atomic swap to ‘fail’ and the originator to get their funds back after a set amount of time, usually 24–48 hours.
Assuming the originator is honest, the opposing party makes their side of the transaction using the same hash and modifying the amount and who to send the coins to. The originator then goes back to the opposing party and looks up their new transaction. If it includes the correct information, then they proceed. Again, if not, no action has to be taken and both transactions will hit their time expiration and be refunded to the original creators.
Assuming the originator is honest, the opposing party makes their side of the transaction using the same hash and modifying the amount and who to send the coins to. The originator then goes back to the opposing party and looks up their new transaction. If it includes the correct information, then they proceed. Again, if not, no action has to be taken and both transactions will hit their time expiration and be refunded to the original creators.
The problem with this process is that it is technically complex for the average user and requires direct communication with the opposing party to coordinate the swap, check transactions, etc. Clove serves to solve both of these issues through automation. Clove at its current state is a command line tool written in Python that automates atomic swaps on 95% of the cryptocurrency market. If you recall, most major blockchains are simply modified versions of Bitcoin and Ethereum. Both of these blockchains support atomic swaps, which means that Clove automatically supports the swapping of Bitcoin, Bitcoin-based coins, Ethereum, Etherum-based coins, ERC20 tokens, and ERC721 tokens. Furthermore, Cilantro natively supports atomic swaps out of the box, which means that the Tau coin will be a transaction-cost free way to swap assets in the cryptocurrency world. Our plans for Cilantro include supporting the creation of tokens on its platform as well, which means that new classes of unique and swappable tokens and coins will emerge following the launch of the Lamden mainchain.
Some other blockchains that support atomic swaps are also being investigated. For example, Neo and Neo assets follow a similar smart contracting model to Bitcoin and so they are a promising addition to Clove’s atomic swap automation portfolio. An investigation into Eos and other smart contract blockchains is ongoing. It should be noted that Cryptonote-based coins such as Monero and Bytecoin do not support atomic swaps because they do not include a smart contracting language under the hood like Bitcoin, Ethereum, and Cilantro do. However, there are experiments in other methods to make this work. Similarly, NEM and NXT don’t seem to support atomic swaps as easily at this time, although preliminary research into supporting them via other methods seems to exist in the community which Lamden is pursuing.
Cilantro — a new blockchain
There always seems to be confusion as to what Cilantro exactly is. Is it the main chain of Lamden? It is just a tool to create new blockchains? Is it a blockchain that is for enterprise deployments? Here is the explanation:
Cilantro is a piece of software that allows the modular construction of blockchains. It is the piece of the puzzle that allows rapid development of decentralized systems while not restricting the possibilities of what the systems can do. That being said, Lamden’s main deployment of Cilantro is for atomic swaps. This deployment is what holds the Lamden Tau coin and is what our first decentralized application will be for the public.
What this deployment serves is two purposes: one, provide free and fast transactions and atomic swaps to introduce true interoperability to the crypto space in a way that is not controlled by a singular party, and two, demonstrate a successful deployment of the Lamden suite to create brand new blockchain applications.
Main Motivations of Cilantro
The mission of Lamden is to increase the adoption of blockchain such that innovation can flourish. To do so, a blockchain with attractive features must exist. That is not the case at this point in time. If you look at how Bitcoin and Ethereum work, their interfaces are extremely complicated and convoluted. Both projects have done poor jobs at writing clear documentation which explains their complex systems.
Furthermore, if you look at the transactional payloads that make the software work, it’s decidedly convoluted. This alone is a massive barrier of entry for people to get into blockchain. Remember when you first got into crypto? Do you remember where you started off? How did you get your first coins? Did you sync up a wallet on your computer? Did you run a full node?
A lot of the user experience of onboarding people to cryptocurrency is quite negative. That’s the overarching motivation for designing Cilantro. These design decisions inform our development efforts.
Transactions
One of the most important aspects of Cilantro is that the standard transactional payloads are free. This allows people who want to experiment with the technology to do so without risking funds or dedicating a budget to transaction fees. An individual can have a single Tau coin and send it around the network without losing any portion of that coin in the process.
As discussed before, the way that we get away with this is through a client side proof of work puzzle. This effectively rate limits the transactional generation time to around 400 milliseconds per transaction. This is sufficient to protect against DDOS attacks which would require millions of transactions to be submitted to the network at a time.
However, if some people want to submit transactions at a higher rate than about 2.5 per second, they will have to pay a ‘stamp’ transaction fee. What a stamp does is allows a sender to bypass the proof of work required for a transaction. This allows serious actors to utilize the network without implementing expensive hashing hardware, which is one of the downsides of the Nano platform and why Nano has trouble implementing with existing exchange infrastructure.
Allowing a user to stamp a transaction opens up a potential attack vector where a user with no stamps sends a multitude of transactions to the network. Even though they would all fail, it would introduce a massive clog to the system. Thus, to purchase stamps, a user has to stake the number of stamps they want. This stamp ledger is shared amongst all nodes so that they know at all times who actually has stamps and who doesn’t. This provides a simple lookup mechanism where nodes can deny users they know have no stamps.
However, it doesn’t protect against an attack where a user generates a million wallets and sends a single transaction from each of them with a stamp that doesn’t exist. This would require a massive lookup time for each new address and cause the system to bog down. To fix this, we implement a bloom filter on each node that is attached to each wallet. When a wallet stakes stamps successfully, that wallet is added to the bloom filter. When the wallet comes back, it can pass through the bloom filter successfully without the node (most of the time) needing to look up if they actually have stamps. This works for the opposing side as well. Bloom filters rarely have false positives where they would think that a wallet has stamps when it doesn’t, but it never has false negatives. Thus, they can reduce lookup times for spam stamp attacks by 90%+.
This mechanism works great for static transaction types. One transaction needs one stamp which is fulfilled by some number of Tau coins. However, Cilantro supports smart contracting, which means that transactional payloads can vary in how much data they are sending over the wire. This means that an attacker could purchase some stamps legitimately and create transactions with huge payloads and spam them throughout the network.
Let’s say the stamp fee is 1 Tau coin. The attacker purchases 1000 stamps for 1000 Tau coins. The attacker then generates 1000 transactions with 10MB payloads a piece. This means that they can effectively push 10GB of data through the network without any friction. This obviously will bloat the system and drag it down.
To solve this, we introduce a variable where each stamp does not cover a transaction, but rather a fixed amount of data. What this also means is that we can have each proof of work puzzle cover a fixed amount of data as well.
One standard transaction: 350 bytes
One POW proof solve time: 400 milliseconds
One stamp staking costs : 1 Tau (in theory)350 bytes = 1 Tau
1 byte = 0.00286 Tau1 MB = 1000 KB = 1000 bytes
1 MB = 1,000,000 bytes = 2857.14286 Tau
10 MB = 28,571.4286 TauEtc. Etc...
Above are some example figures on how much it would cost to send a megabyte payload of data. These numbers are theoretical and can be voted on by the network to adapt to economic conditions (more on this in a later section).
Assume:
10 masternodes (endpoints of the system, discussed later)
1 Gb/s up link per masternode
10Gb/s capacity1 Gb = 0.125 GB (gigabit vs gigabyte)1.25 GB/s capacity = 3,571,428.5714 Tau required to clog the network for a single second1,428,571.4286 seconds to solve a 1.25 GB payload puzzle....23,809.5238 minutes......396.826 hours......16.53 days...This is obviously infeasible.
You can see that this new variable adds a massive level of security and anti-spam to the point where it effectively roots out attackers while keeping good actors who actually want to use the system for its intended purpose protected and able to send free standard transactions.
Better Consensus
Proof of Work as a consensus model is horrible. It’s tremendously wasteful and does nothing to the actual operation of cryptocurrency besides doling out rewards to miners. This may be a decent distribution mechanism, but there’s a point where proof of work gets in the way of performance. Merely looking at confirmation times for transactions on the Bitcoin blockchain make this fact plain as day.
All newer blockchains that are being released like EOS and NEO have done away with proof of work because they also agree that it is not efficient. Ethereum is also moving away from proof of work to proof of stake.
At a deeper security level, what Cilantro does consensus on differs from other platforms. Cilantro supports smart contracts, and actually all transactions are processed through smart contract logic (explained later). Ethereum does something similar. However, when a change in state is processed on Ethereum due to a smart contract, the resulting output of the transaction is represented in byte code. This byte code describes actual operations on a virtual computer called the EVM (Ethereum Virtual Machine).
Cilantro does not do this. Rather, Cilantro outputs actual SQL query strings which update certain parts of the global database table. This probably sounds sketchy initially to a developer that knows how Ethereum and other VM styled blockchains work. This method is actually safer and less prone to errors.
Virtual machines or any function for that method are input / output devices. An input goes in, which in this case is a transaction, and output goes out, which is byte code in Ethereum and query language in Cilantro. When you are debugging your code, you want to know if the behavior is actually doing exactly what you want it to do. When presented with byte code, you simply have to trust that it is executing what it says it is. There’s no way to read it.
With a query language, it’s written in syntactical English. It’s easy to understand what is being modified, replaced, deleted, inserted, etc.. You don’t have to worry about trusting the system because you can plainly read what it is outputting.
Furthermore, SQL is a ubiquitous language. There are many flavors and variants of it. We chose MariaDB with a MyRocks storage engine because it features SQL queries to interact with and stores data with software that is faster than LevelDB, which is the de facto standard of other blockchain projects.
This means that companies already using SQL, which is the majority of them, can just plug in Cilantro into their current storage engine and use the same SQL queries that they have been using for their current business logic applications. It also means that they don’t have to retrain their staff to learn some strange new blockchain thing that they heard their grandkid say once.
Also, the EVM and VMs, in general, are Turing-complete. This means that the complexity space of how they operate is infinite. Thus, when executing code, the output could literally be any number, value, or operation in existence. With SQL, it’s completely bound by read / write operations. There are no memory spaces and, therefore, no low-level attack vectors that could disrupt the intended operations.
This is extremely important because it means that, theoretically, there is an infinite number of potential security attack vectors in the EVM that have yet to be discovered. The Augur project not too long ago had to port their ERC20 token to a new contract because they discovered a bug with the compiler that created a smart contract that did not behave exactly how it was written. The edge case of this vulnerability allowed anyone to cause the contract to completely freeze if they sent the write data payload to their token contract. We can only assume there are many other bugs like this have yet to be discovered.
Open Governance and Types of Nodes
One of the reasons for having free transactions is also the fact that a lot of platforms’ fees started off early in the beginning and have ballooned to these massive figures such that it doesn’t make sense to use them anymore in a serious capacity.
Look no further than the Bitcoin Core vs Bitcoin Cash debate to see this entire concept of transaction fees being played out. What is especially unfortunate is that Bitcoin’s average transaction cost largely depends on the demand of the network. During periods of high usage, the transaction fees skyrocket. During times of low activity, they normalize to a “reasonable” one or two dollars.
However, a lot of people believe that the transaction fee problem can simply be solved by increasing the size of the blocks. The problem is that there is no good way of voting for this measure to occur, and the solution is ultimately bound by the adoption of the new system, hence the BCash fork. It would be interesting to see this scenario play out if some sort of middle ground was forced or if the system had to come to a new conclusion in a certain amount of time.
With Lamden, we foresee this being a problem not just with Bitcoin, but with immutable ledgers altogether. If there isn’t some way to modify the variables and policies in the system that is baked into the platform, said platform will most likely come to forks and splitting points. An increased amount of forks leads to a weaker and weaker project. Alternatively, we feel that it is important for a community to find consensus and compromises to problems pertaining to the central technology and architecture of the system.
Furthermore, there is far too much redundancy in the current Proof-of-Work system that dominates blockchain today. Every node has to have then entire blockchain synced up before they can make any transaction. This is an inordinate amount of resources for someone who just wants to get involved with the system but doesn’t want to invest $500 on a dedicated server.
This has been circumvented via services that act as nodes so that other people can use them, such as Infura for the Ethereum blockchain. But this ends up just centralizing the entire structure that is supposed to be decentralized in the first place.
Also, the amount of work that it takes to process a single transaction on a Proof-of-Work system is enormous. This directly affects the number of transactions that can go through the system per second. Current systems are more focused on the aspect of decentralization at all costs rather than the performance and usability of the system.
To solve all of the problems outlined above, we introduce several types of nodes that have different responsibilities and rights within the system. This allows us to distribute the workload such that it is far more efficient than current systems.
The nodes of the Lamden system create an assembly that not only operates the network, but also votes on the key factors of the system and how it adapts over time to ensure longevity.
Obelisks (aka, masternodes)
Every blockchain has several components to it: the entry point of transactions into the system, the routing of those transactions throughout the network, the processing of those transactions to state changes, and the storage of the transactions in the form of blocks.
Obelisks take care of two of those responsibilities. They serve as the entry point into the system and hold the blockchain data. Like their monumental counterpart which they get their name from, they are landmarks of the system. They are static servers which the users of the networks can easily find and interact with. This creates a reliable backbone to the system.
Obelisks come in two flavors: primary and secondary. Primary Obelisks serve the most purposes on the blockchain. Not only are they responsible for storing the blockchain, they also have the ability to vote on supreme policies that affect the underlying architecture and behavior of the system.
These policies include things such as the tuning of the consensus algorithm, block times, etc. Only people with a deep technical knowledge should be allowed to alter these variables.
This requires some level of personal trust. We can obviously see a situation where Primary Obelisks are compromised by parties that want to destroy the system and purposely vote on bad policies. To mitigate against this, all Primary Obelisks must unanimously be voted in by the prior standing Primary Obelisks. While anyone can be a Secondary Obelisk, only those that pose the necessary qualifications for voting on key issues will be able to become Primary Obelisks.
Is this decentralized? Yes. While this concept introduces levels of influence to the network, it still does not rely on a centralized authority. Primary Obelisks are distributed and will mutate over time.
Secondary Obelisks have all of the same responsibilities and benefits of Primary Obelisks without the power to vote on key issues. They are still required to store the blockchain and still required to be public endpoints to the system, which means that they have to support a large number of incoming web requests from clients pushing transactions through.
Besides that, both Primary and Secondary Obelisks share the same reward structure. There is no difference. Why would someone be incentivized to be a Primary Obelisk in this case? Because they have a personal fascination with the software and a personal motivation to preserve it. Not everything in crypto is a cheap ‘economic’ trick where a system has to dispense treats for every good behavior. To create more complex systems, a system has to tap into more complex levels of needs and rewards.
Witnesses
To prevent against collusion, Witnesses stand between Obelisks and Delegates. Although we have not explained Delegates entirely, they are similar to Delegates in DPOS systems such as Bitshares and Lisk. They are responsible for constructing the blocks and making sure that transactions are valid against the current state of the blockchain. These nodes are voted in by the network to make sure they are decentralized players. Bad actors are voted out.
In a system that does not have Witnesses, Obelisks and Delegates could collude together to keep a group of Delegates in power indefinitely. They would do this by altering the vote transactions on the blockchain on storage. Because Obelisks are the ones that store the blockchain and Delegates are the ones that mint them, both have to power to include and omit whatever they want. Witnesses stand in the middle of this by verifying that transactions are legitimate and actually pass through the system.
In the case that Obelisks and Delegates collude to keep a select group in power, Witnesses can simply stop sending transactions to those Delegates and send them to the group that they actually voted in. In any event in which this were to happen, the system would suffer performance issues and become useless which destroys the very thing that Obelisks and Delegates would be trying to preserve or game, rendering this attack vector useless.
Witnesses also earn Tau from being chosen as a verifier in Oracle transactions which are the decentralized way of validating an atomic swap on the blockchain. Witnesses can earn more by being voted into the Delegate pool.
Delegates
As just stated, Delegates are the ones that mint the blocks in the system. They are voted in by Witnesses based on their level of trust similar to the Lisk system.
However, unlike Lisk, election rounds are frequent. Each voting Witness has to stake an amount of Tau to receive a single vote for that round. These votes are sent throughout the system as transactions recorded on the blockchain. From there, the wallets that are valid Delegates are recorded and agreed upon publicly, which informs Witnesses where to then send transactions.
Furthermore, only the select top half of Delegates get the full reward. Delegates are pushed to the back of a FIFO queue when they are determined to be offline, miss a block, or are out of consensus even once. They then have to wait for their wallet address to be pushed back up the queue to the halfway point to receive the full reward again.
While this sounds exceedingly harsh at first, it breeds the best nodes for the job. We want to reward highly available and fast machines. This requires a high bandwidth, a decent amount of storage, and constant uptime. If any of those metrics are subpar, the entire system becomes subpar. There is a lot riding on Delegates to perform their job. Ultimately, the speed requirements of the network lay on their shoulders during the time of consensus. Thus, we want to weed out people who do not have the right hardware for the job. Also, as time goes on and more technological advances happen in the world of computing, the Delegate pool will dynamically adjust itself to keep the ones with the latest and most performant tech at the top of the queue.
Some may think that this sounds elitist. However, it is just the opposite. Systems that try to make ASIC resistant algorithms want the distribution of their cryptocurrency to be flat. However, our distribution already happened, so that is not an issue. Thus, we can now focus on making our system accessible to the masses. Bitcoin and Ethereum are elitist due to the high level of skill required to interface with it.
To lower the barrier of entry, we have to make the system easy to work with. Speed, throughput, and free transactions are vital to making these values a reality. The best way to guarantee that all three of these are accomplished is by developing a system that optimizes towards supporting infrastructure that is top-tier.
Decentralized Governance
I covered our concept of decentralized governance here. What decentralized governance is good for is a fair way to introduce changes to the system without any disagreement. The inspiration is taken from Bitcoin which forked into the contentious Bitcoin Cash as of 2017. The main purposes of the fork (although there are a great deal of personal and political reasons as well) were completely technical. Increasing the block size would have prevented such a thing from happening. However, there was no way to decide or compromise on a solution. Rather, and this is true for all blockchains currently, if there is some disagreement, the chain will just fork. It’s a binary situation. Even if only 30% want to fork, they will fork. This then causes a loss of 30% of users to the chain. Forking also shatters the perception of agreement for the project and begins to blur the lines between which one is the ‘real’ chain.
Thus, we introduce variables that can come to a middle ground and come to decisions fairly. Each of these variables can be voted upon in a completely open manner. Everyone can read the results, and everyone can then agree about the changes involved.
In terms of a user experience, voting would occur in a front-end client such as a wallet where proposals are submitted to a block and stay active for a certain amount of time. During that time, clients can read the blockchain, see what the proposal contains, and vote on it. After the vote is finished, the blockchain automatically updates itself accordingly. For example, if the proposal is to add native token support to the system, the code for doing so would be submitted on the blockchain so that the community could audit it. From there, people would vote on whether or not the specific implementation makes sense. If everyone agrees, that contract would automatically be installed onto each node’s computer. This allows updates to occur on the fly and with community engagement.
For attackers, they would have to bypass this metric by running a node that has modified code. They would then have to not install the new smart contracts or updates. This would then cause them to behave differently. For example, that node would not know how to process token transactions when people started using new features. This would in effect cause them to be out of consensus and breakdown. Thus, it makes little sense to spend the effort of modifying and rejecting proposals just to become out of consensus.
However, assume that a vote is close. It’s 51% to 49%. Could the blockchain split? Bitcoin Cash was able to successfully split because it made its chain more profitable to miners so that people switched over to support it. Because Cilantro has no proof-of-work or miners, the action of forking is much more convoluted. A rogue group would have to be in consensus regarding a single policy they do not like, write the software to modify the behavior of the auto-updating mechanism, find new Obelisks, Witnesses, and Delegates, and all the while expect people to then continue forward with this forked chain, which has no economic incentives besides a political grudge. While it is possible, it is much less likely to happen than with proof-of-work chains, meaning that if you can stomach proof-of-work chain forks, you can stomach the slimmer risk of Cilantro forks.
Fees
While standard transactions are free on the Lamden blockchain, not all transactions are. We discussed stamp transactions prior. Oracle transactions to validate a piece of web content can take a lot of time and require potentially 100+ nodes to participate. This costs a fee as well.
However, instead of going to a single party such as miners in a traditional POW system, fees go to the relevant party that did the majority of the work and are used as incentives rather than block rewards.
Stamp transaction fees go to Delegates. Oracle transaction fees go to all three parties depending on which parties participate in the particular transaction. Executing smart contracts and pushing large amounts of data will have to be ‘stamped’ or solved. These would go to delegates as well.
Obelisks have the most workload of the network, however. Thus, they receive an additional tip from every fee to make sure that they are well funded and incentivized to remain up and running with modern hardware.
Furthermore, Lamden does not believe that they can predict the optimal ratios of fee distribution over time. That is why the fee structure is something that is voted on in the open governance model. It may turn out that stamp transaction fees should go more to Witnesses than Delegates for some reason. With the open governance system, we don’t have to decide or pretend to know the economic situations and politics of the system prior to deploying it. We can allow the system itself to come to a balance.
Developing New Systems
While Lamden’s main deployment of Cilantro is specifically for atomic swaps, Lamden’s mission statement is to create an easy framework for the development of new blockchain and decentralized systems. Thus, it is required that Cilantro serves as a launchpad for completely custom and new systems.
This seems like it would be difficult because Cilantro is a specific implementation of a blockchain. How do we take code that is static and turn it into a dynamic framework that allows creativity and mutability?
Looking at the Status Quo
If you want to make your own blockchain, your options are few. Furthermore, if you want to use something out of the box and just install smart contracts, you have even fewer options.
Back in the altcoin days, people would just fork the Bitcoin or Cryptonote code, tweak a few variables, pump out a BitcoinTalk ANN thread, and hope that people start using it. However, the variables that people changed were nearly entirely arbitrary to any decent amount of complexity.
For example, Forknote, a Cryptonote generator allows you to modify simple variables and assumes that you are using the blockchain merely as a cryptocurrency. Altcoins based on Bitcoin generally just alter a file called ChainParams.cpp which is essentially a configuration file for minor tweaks in how blocks are processed, the difficulty over time, etc.
These are not compelling modifications.
Ethereum lets you deploy a private network to deploy your own smart contracts on it. This is nice if you want to turn down the price of gas to zero to allow free transactions to occur on it. However, the dimensions of customizability are still limited to what Ethereum lets you do. There’s no way to introduce new node types, actors, etc. It’s all contained in the scope of the EVM, which is a small subset of what happens when Ethereum is running.
For people who want to develop something from scratch, they can use Hyperledger, which is a framework developed by IBM and associated with Monax and the Linux Foundation. Is it well backed and highly regarded as the best solution for enterprise blockchain development at this point in time.
However, Hyperledger is hard to use. There are a lot of new concepts a developer has to learn before they can even start using the framework. These concepts are not just the standard crypto jargon that makes your non-crypto friends scratch their heads. These are concepts unique to the Hyperledger framework that are not very intuitive.
Furthermore, Hyperledger uses Node.js and Go as their primary languages. Major enterprises shy away from Node.js because it is not seen as highly performant or safe. They don’t use Go because the talent pool of Go developers is very slim. Even though the performance of Go is highly regarded, enterprises want to use software that can be serviced easily over a long period of time. This is one of the reasons why they use Java. Java code is completely backwards compatible so companies do not have to refactor it and spend money getting it to work when the next version comes out. In a similar vein, enterprises don’t want to spend money training their employees how to program Go. They also don’t want to limit the talent pool that they select from. Fewer candidates in the job market means potentially higher demand and potentially too few with the required skill set needed for the job. Companies have been known to refactor their entire codebase from Scala, a special flavor of Java, because they can’t find any developers to manage their code. Scala is generally regarded as ‘better than’ Java for many reasons.
Thus, the two major takeaways are customizability and writing the framework in a language that most people know.
How Cilantro is Different
Firstly, Cilantro is written in Python, which is the second most popular language behind Javascript in the open source world. This means that there is a massive amount of open source code available to use, speeding up the process of development and informing transparent code altogether. It also means that developers can tap into this resource of open source software to add complexities to their code relatively easy.
Secondly, Cilantro is written in a modular fashion that expects addition and mutation of the data structures to occur without a lot of trouble. For example, one of the major design implementations of the node logic is to introduce a state machine. A state machine is a computer science concept that dictates that a piece of software operates differently based on which state it is in. The software can only be in a single state at a time and transitions to a new state depending on the inputs and actions performed on it.
Consider a gumball machine. A gumball machine can be in the waiting state or the dispensing state depending on whether or not a coin is inserted into the machine. The rules of how the gumball machine works therefore depend on which state it is in.
Similarly, a node has different states depending on its lifecycle. All nodes have boot states that perform operations before accepting transactions. In this state, a node may be catching up to the latest block or finding peers. During this time, it will reject all incoming transactions because it is not ready to process them. When it is ready, it will transition into a new state.
More complex states exist for things such as consensus where there are multiple steps to confirming a block that we only have to worry about when the time comes to do consensus. Thus, rather than writing the whole thing in a singular piece of code, the state machine pattern makes things easy by assigning the right actions for the right time.
But what if we don’t want to even perform consensus? Rather, what if we want to shard the blockchain and have a method to process shards, check that data exists, and fetch data for different operations? This type of behavior does not exist in the Cilantro codebase at this time, so it would be up to the developer to code it themselves. However, because the state machine is implemented, it makes adding several new states to a node as simple as subclassing the base state and adding the new logic to it.
Furthermore, it is extremely simple at this time to assign different logic to different messages. In the current implementation of Cilantro, there are Standard Transaction messages that come from Obelisks. There are also Signed Merkle Tree messages that get passed around during consensus. We want to ignore transactions during consensus and only listen to our special merkle tree message type. To do this, we would only write the logic to process these specific messages in their respective states. All other noise is ignored on default.
These design decisions make it extremely easy to create new complex political systems on a decentralized network and opens up the space to wild new innovations that have potential to topple over many of the tech titans in the industry today.
Smart Contracting
For some people, implementing a system that retains even more of the standard Cilantro behavior is ideal. The base system gives the developer high throughput with a good path to decentralized governance. They may just want to add features to affect how transactions affect balances, ownership, and attributes like that.
This is exactly why we have created Seneca, a subset of Python that interacts with the Cilantro blockchain. Seneca looks at the blockchain like a database driver looks at a standard web application. The blockchain is simply a mutually agreed upon data store that people can modify and access all together. Thus, Seneca offers an interface that treats data like a tabular datastore and uses real SQL to construct the state of the network.
This means that people familiar with MySQL and other SQL type databases will not have to learn some new, esoteric paradigm to be able to use Seneca. It also means that more complicated data applications can exist that mimic current web applications. Things such as user tables, role-based access control, and tighter integration to established technology are all possible in an interface that is fast and understandable.
One of the main problems with Ethereum is that their smart contracting language runs on the EVM which is in itself a different type of computer that the Ethereum Foundation made themselves. All operations on Ethereum are limited to what the EVM can do itself. Data access is poorly defined. There are not complex data types such as dictionaries or tables. This means that programmers have to get creative with how they describe data that goes beyond simple storage.
Also, most people despise Solidity, the main smart contracting language used in Ethereum. It is obtuse, makes little sense, and is its own language entirely rather than being an API to the blockchain.
Seneca is different. Seneca is pure Python code. We’ve taken the actual Python AST (the mechanism that turns English syntax and turns it into computer operations) and modified it so that it behaves the way we want it to. For maximum security, Seneca disables features on default and only whitelists commands that are vetted to be secure. For example, for loops and while loops do not exist in Seneca because they could cause infinite execution. Instead, we use maps and filters which require a defined execution space prior to operation. This removes the ability for the creation of never-ending loops.
We have also added some nice features to Seneca. So that people can build off of other smart contracts on the blockchain, we’ve added an ‘exports’ feature that is similar to the one in Node.js. This allows developers to explicitly define what methods can be used and accessed by other parties. This is an important distinction from Solidity where all methods are assumed public unless otherwise specified. This is the main reason why the Parity hack happened, as outlined in the hacker’s own confessional.
Besides being generally safer, Seneca code is much more legible than Solidity. The outputs are pure SQL queries that are written in English so developers can quickly spot if something has gone awry.
Even better yet, because Seneca is a subset of Python, all tooling that is made for Python is automatically compatible with Seneca. This means all unit testing modules, all IDEs with syntax highlighting, and even IPython are completely supported out of the box. As a developer who wants to learn Seneca, you do not have to learn any new software tools, install any funky and proprietary modules, or deviate from what you are already comfortable with. This is an invaluable addition and lowers the barrier to entry even further for potential smart contract developers.
Seneca as a subset of Python is also able to be mixed in with full Python code natively. This means that your web applications, machine learning applications, and hardware applications that already run on Python can connect with the Lamden blockchain and run smart contracts out of the box! Whether that’s accessing data, calling specific methods on smart contracts, or deploying new smart contracts altogether, there is no extra software besides the standard Seneca framework (hosted on PyPi) that needs to be installed.
This means that developers, when choosing between several blockchain and smart contracting solutions, will gravitate towards Lamden naturally. There is no other system that provides a smoother integration with other applications. Furthermore, Lamden is the only system that allows discovery and experimentation without wasting cryptocurrency in the form of gas and other assets. Because of our free transaction model, developers can interact with the main chain without risking capital as they explore how to use the software.
Long Term Viability of Lamden
Open source software runs the world. It powers the internet with web servers such as Apache. It stores our data with systems running Linux. It’s integral to the existence and progression of technology altogether. However, open source software has a bad business model: release it for free and never expect people to pay for it. So how does a project perpetuate itself in the long term?
Lamden is committed to the mass adoption of blockchain and decentralized systems as a whole. That’s why we are making our suite of software tools. But, our development does not stop there. Lamden plans to release independent business units that utilize our suite of tools to generate streams of revenue for the organization. Maybe Lamden makes the next decentralized social media platform that we used as an example in this overview. That application could be monetized in a variety of methods. The proceeds from this application would go back into the Lamden development fund for further work improving our tools and releasing exciting new software.
In fact, Lamden has recently kicked off the production of a cryptocurrency exchange and fiat backed tokens which can be integrated into applications more easily and cheaper than alternatives such as Stripe and PayPal. Because Lamden is so heavily integrated in the blockchain space, we already know what efficiencies in the industry can be introduced utilizing this new technology.
We also plan on utilizing our Lamden Labs innovation fund to kickstart other peoples’ projects using our tools. In return, Lamden may ask for a share of tokens or some amount of revenue. These types of ventures make it easy for Lamden to support a wide array of projects in return for indirect streams of revenue that do not have to be managed directly by the organization.
Finally, to initially bootstrap the network, Lamden plans on hosting and running the majority of Obelisks. As time goes on, it won’t be necessary to continue running them. We want our network to be run by a decentralized community of users. So, we will start to power off our Obelisks as the system flourishes onward. On the reverse side, Lamden will keep a few Obelisks running and pipe the rewards directly back into the business. In fact, our largest single holder of Lamden Tau has already committed to staking the majority, if not all of it, into Obelisks, Witnesses, and potentially Delegates and returning a portion of the rewards to Lamden. Support like this can accelerate our success.
Regardless of the specific route we choose, we have countless paths to the long-term viability of this project and bringing blockchain to the mainstream to revolutionize the way we use software. The internet created a more connected world which lead to the worldwide pursuit of truth, rationality, and betterment through information sharing. More civil rights, better policies, and overall well being was the result. What will happen now that the same thing is happening in the world of finance? Only time will tell.
