Ledger is a part of the project code that defines the principles of data development and storage in individual system nods (in our case, these are computers and other devices in a blockchain network).
There are many protocols on the Internet, and some of them (such as the most ancient one called TCP/IP) might be familiar even to people outside of the IT industry. New protocols are being developed to improve the quality of service and perform different actions. For example, sctp is a protocol for multimedia communication that keeps multimedia data sent to several users at once synchronized. However, many software solutions, such as Skype, work on top of old protocols. As a result, today the sctp protocol is similar to a hydrogen engine: even though it exists, people still prefer gasoline motors. This happened because the industry did not want to take a new path, and every developer suggested their own solution to the issue with old protocols. Because of that, the manufacturers of network equipment, commutators, and routers also decided to save money on additional R&D and refused to support sctp. The “if it ain’t broke, don’t fix it” approach is understandable. It is also clear that all industry players are waiting for someone else to do the job instead of them.
At Power, we follow a different logic and understand the need for new approaches. Having discovered sctp, we started using it to establish communication between Ledger 1.0 instances on different devices. Then we found out that the industry was too slow to react to our solution which led to compatibility issues. We had to make adjustments and switch to UDP, and it became the basis for Ledger 2.0 that develops data in our system nods.
Please find some FAQ about Ledger 2.0 below.
— What is the difference between Ledger 2.0 and other blockchain systems?
— Bitcoin blockchain doesn’t have the so-called system state. A state is a status of all variables at a given moment: account A has this many variables, and account B has that many of them. Plus, it includes all the information from any given block. The next generation, Ethereum, uses a mixed state approach: there are blocks with lists of all user transactions, and there is their result—a current state. Moreover, each user has a balance indicator. It does not require a separate block but is presented as a sum of all incoming and outgoing transactions. Therefore, instead of storing all transaction information, Ethereum only displays the most recent value, i.e. the state of all valuables as of a given moment that slightly changes with time. However, this approach has its disadvantages: to get your data, you have to turn your computer on, obtain all transactions, and apply them. We went one step further and gave our customers an opportunity to check their state at any given moment without diving deep into transaction history.
— How is Ledger 2.0 different from Ledger 1.0?
— In Ledger 1.0, all account data was stored as a single data block, while in Ledger 2.0 it is presented as a tree where each leaf corresponds to a variable. In mathematics, this representation is called a Merkle tree. Regardless of the type of data storage, all data is verified using hash functions. However, when the data is stored in bulk, it has only one verifying hash for the whole block, while in the Merkle tree every bit of information gets its own hash.
Previously, the Merkle tree was used to create verified account data. One cell located at its root (unlike real-life trees, in mathematics trees have roots at the very top and branches below them) contained verification information for all the data in a blockchain, and all account branches stemmed from it. But in Ledger 2.0, each account is not a branch, but a whole tree.
— Does it mean that this scheme requires more capacity?
— On the contrary, it now needs less. Previously, every little change required the recalculation of the whole system. Today, only one branch has to be recalculated, and then the data can be sent directly to the top.
This arrangement leads to several interesting consequences.
1) Previously, in order to work with their account via a light client (a browser), a user had to upload all account information and then break it down to obtain the most recent data. In Ledger 2.0 this can be avoided.
2) Nods are easier to synchronize after downtime, e.g. if one node was inactive.
3) In the future, this scheme could be used in smart contracts, as they would be able to request access only to relevant bits of information, not to the whole account.
— Do other blockchain systems have similar solutions?
— Almost all distributed ledger technology (DLT) projects rely on the Merkle tree concept to a certain extent. However, I haven’t seen anyone use it to store and verify individual variables of an account. In Ledger, we have a special LStore function that allows a user to store data in their account in variables. Without it, the users of other projects won’t be able to receive verified variable values from their accounts.
— What about safety? If a web client can make requests, can it also cause any harm?
— Like in any public network with PoW consensus, in Ethereum anyone could add a node and obtain data. However, it is quite expensive and not affordable to everyone. Some users have to resort to a third party service that accesses its node, searches for an account, and receives data through an intermediary. In this scenario, it is impossible to check how old the data is and whether it has been changed. In our scheme, the data is received directly from the node, and there is a confirmation that all transactions in question happened in a given block, at a given time, and without any adjustments by third parties. If the data has to be made private, we use a system of access keys.
