Introduction to the LEO programming language
Aleo gathered a solid team of compilers to create a very ambitious language compiler scheme. The main purpose of this work is to allow developers to maximally use evidence with zero disclosure in their applications — this is achieved by minimizing cryptographic knowledge requirements. So how exactly Leo reaches it and what do you need to know to start using it? Let’s figure it out.
First of all, let’s briefly remind yourself what proof with zero disclosure. This is some of the data that proves that we fulfilled the calculations correctly; For example, that we used a closed key to send any NFT or that we have some kind of attribute that allows us to update the state of the application. In addition, it allows us to maintain some data in the secret if we wish that; For example, we do not need to disclose that private key that we used to send NFT. And these evidence is also much less than all calculations, so it will require much less storage space (in the chain) and will be faster.
This is a very abstract idea, therefore, it may be more relevant if we connect it with the problems of scalability that we see in the industry right now. Take a look at the difficulties faced by various networks when receiving a sufficient number of transactions per second, and on the requirements for scaling solutions to expand online game-game capabilities. Tools such as state segmentation were useful, but we need to add more to support the growth of these uses (and future use options we do not even know about). Moreover, ZKP also allow us to hide the data that we do not want to disclose; Of course, it is impossible for other scaling solutions.
Now, how do you make ZKP? Well, it is done for us with the help of a system of evidence and something that is called a ZK scheme — in fact it is a scheme that we need to build, and this is what Leo will do for you! Libraries that turn the ZK schemes in Prufs already exist, so far people used these libraries directly.
Think about the device you are using right now, inside it there are schemes that perform all these calculations, right? Well, did these schemes not just valves and not with whistles whistling through them and units? ZK schemes are very similar, except that instead of the valves and not, they are made of addition valves and multiplication, and instead of zeros and units, we have numbers from zero to P, where P is a phenomenally large simple number. You begin to understand that we can perform as many calculations in ZK schemes, how much and in real schemes?
Now we approach the essence of the problem, the reason why Aleo puts so much money into the creation of the LEO scheme compiler — the transformation of high-level application ideas in the ZK scheme phenomenally slowly, because you need to manually collect all the elements of addition and multiplication to represent what calculations should Represent your application. I mean, how much time you have left to write ordinary applications, if you had to connect Nand valves to build computations … It sounds not very fun, right?
Well, this is the current status of creating a ZK scheme. In fact, you must work at the level of constructing the scheme, because there is still not enough infrastructure to automate low-level repeating parts. And in fact, it’s still worse. Not only do we still have these automation tools, there are still many cryptographic knowledge even in order to start building ZK schemes. To overcome this burden, in most cases, people need several months of full-time learning. It does not sound very good for product development.
LEO is a RUST-based programming language with static typing created to write private applications. It is intended for developers who can intuitively build aleo blockchain, providing a basis for a private decentralized ecosystem. This is the first-known programming language that represents the test environment, the packet registry, the import converter, the remote compiler and the generator theorems for the general purpose applications with zero disclosure.
Let’s jump forward and say that you wrote a LEO program, similar to bubble sorting in the image above — What actually does leo when you run the program?
It takes your code, creates a checkout scheme that represents the calculation you want to run, fills in the input conductors with the desired values, starts the scheme, generates check / check keys, and then combines all the corresponding data in ZKP. For example, you can run it on the input data in the image below.
But we said that you don’t need a lot of cryptographic knowledge at all to use Leo, so what is this for creating proof? Summing up, we can say that Leo displays the proof that you fulfilled your calculations correctly, which means that if you run the scheme described above on a certain array and present an output array along with the proof, any observer will be able to confirm that the massif really was Sorted by testing the evidence, not an array.
It may not seem so much if the array contains only 10 elements, but when we start working with data structures that have millions of elements and more complex calculations, test evidence (which is always one size!) Begins to transmit much more value. But this is not a post about how to benefit from ZKP, this post is designed to help developers learn LEO so that they can create valuable applications.
Leo also makes more than just creates a scheme for you and generates proof based on it. It is filled with functionality that helps to reduce the development time. Testing platform, packet registry and import converter work together to save developers a lot of time, ensuring that external functions are easily imported, and that the code really does what expected from him.
When you build an ecosystem, the main purpose of which is the development of scalable private applications, one of the best ways to stimulate growth — eliminate as many obstacles as possible when developing applications. This is what the lion helps to achieve. If you want to learn more, look at the playground or documentation for developers.