- XEL 3XL PROGRAMMING BACKGROUND FULL
- XEL 3XL PROGRAMMING BACKGROUND VERIFICATION
- XEL 3XL PROGRAMMING BACKGROUND CODE
- XEL 3XL PROGRAMMING BACKGROUND FREE
This has a very simple reason: very often, bounties are very hard to find and only limited to a hand full per job. XEL’s Blockchain works in a way, that every task has two types of payments: the proof-of-work payments and the bounty payments. In a next step, we need to specify a condition for “proof-of-work” payments. In this case, it is really straight forward: if the number we have stored in m is between 1000, and the value in m equals 1, then consider this a valid solution. This basically is a verify_bty ()which takes a boolean expression as an argument which should evaluate to true for every valid solution that you want to have reported back. This part actually tells the backend system what to be considered a valid solution to your task/challenge – or a “bounty” how it is called in XEL’s terminology. To better understand what is going on here, please take a look at the internal C logic that fills this uint m array: The concept of iterations will be explained at a later point in time. m, the 11th unsigned integer, contains the round number and m, the 12th unsigned integer, contains the iteration that we are currently in. The first 10 unsigned integers are pseudorandom and provide you with 320 bits of entropy in total. ePL has one more array, the so-called uint m array – an array which consists of 12 unsigned integers. Verify_pow ( u, u, u, u) īefore you can understand what is going on here, it is essential that you understand how randomness is introduced into the execution of your code. some randomness for POW function u = m
XEL 3XL PROGRAMMING BACKGROUND CODE
To keep the code clean, we therefore add the entire logic into verify, and let the main function just call verify():
XEL 3XL PROGRAMMING BACKGROUND VERIFICATION
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.
XEL 3XL PROGRAMMING BACKGROUND FREE
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. Functions neither have arguments nor return values.
0 kommentar(er)
