![]() Let’s start taking a look at the verify function first: To keep the code clean, we therefore add the entire logic into verify, and let the main function just call verify(): Surely, this sounds still very abstract to you, but it will make more sense as we dig deeper into this tutorial.Īnyway, for now, things are very easy: in our particular case, there is no possibility to do an asymmetrical verification as finding primes is as complex as verifying them. Or even more importantly, it can cause that valid results found in main are rejected by the Blockchain because they do not pass verify. An incorrect implementation by the developer might cause results to be accepted, that does not really reflect your desired outcome. Especially, it is important to make sure that the logic (in particular, the verify_bty logic which we will read more about later on) in verify actually evaluates to true whenever the one in main evaluates to true. ![]() Important warning: It is the developers responsibility to code the logic in main and verify correctly. If you want to see an example of how this can be done, feel free to take a look at our SAT solving demo. The main() function would carry a complex SAT solving logic, which is more expensive to execute, whereas the verification routine would just assign the result to the boolean formula and check if it evaluates to true. A good example where this asymmetrical verification could come in handy is an SAT solver. ![]() This has a very good reason: XEL allows you more complex programs with a fairly longer execution time inside the main function that it does for the verification routine to ensure an easy and light weight verification on the nodes without stalling the network for too long. Workers, those nodes who are searching for solutions to other tasks, are executing the main function whereas the verification of a solution to the algorithm is done by executing verify(). To understand this a bit better, it is crucial to understand how working nodes are searching for solutions and how the rest of the network verifies these result to make sure that a scientist, who purchases computational power on XEL, actually gets what he has paid for: a correct result. The functions main and verify are needed both because ePL allows for an asymmetric calculation verification. While you can define as many functions are you like (as long as you stay within the maximum allowed complexity and size allowed for your program), you must have the main and the verify function. In our example we have defined three functions: main, verify and test_prime. Again, later on, you will see how you still can easily and comfortably code in the way you are used to right now. This is not a big issue though since arguments and return values can be mimicked by simply using the global arrays. This avoids unpredictable behavior such as out of memory errors and the halting problem.įunctions neither have arguments nor return values. Furthermore, ePL has a slightly modified memory management (and instruction set) which ensures that every node can assess how much memory the program will consume and when it will terminate prior to execution. However, since nodes on the XEL network download and execute code from potentially dangerous sources, a few adaptations were necessary to ensure that code written in ePL can cause no harm to the system it is executed on.įurthermore, since task distribution and verification is done in a decentralized fashion (all nodes which meet a minimum system requirement in terms or memory and CPU power must be able to verify the algorithms’ results in a similar amount of time) it is designed to run in a resource-limited VM. Its syntax is very similar to the C programming languages. EPL is a programming language which was specifically designed for coding algorithms to be executed on the XEL computation node network.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |