A universal translator has always been a coveted innovation for society, and has made many appearances in the works of science-fiction, the most famously-known being the Babel fish. A more practical and flexible translator for programming is now proving to be more necessary than ever with the rapidly increasing demand and adoption of blockchain technologies and smart contracts, which are expected to reduce business costs by at least $50 billion by 2021 in B2B transactions alone. The problem is, business capital disproportionately outweighs the number of developers, with 14 job openings for every one blockchain developer. With this disparity showing no signs of slowing down, competitive salaries for these developers are only going to keep rising, and it means a lot of industries are going to fall behind, fast.

Disclosure: This is a Sponsored Article

This is where iOlite arrives, back in time from the future, seemingly out of a science-fiction novel itself. The revolutionary platform will be providing the ultimate gateway into smart contract design, leaping straight over the current barriers in a genius way. Based on the research done at Stanford University, iOlite Labs has invented an incredibly powerful tool called the FAE (Fast Adaptation Engine). Utilizing machine learning and blockchain technology, this engine’s design has the capacity to quickly adapt to any known language as its input, and outputs to the user’s desired programming language.

What this means is that not only can programmers (in formal languages such as Python, C, JavaScript, etc.) immediately use their existing skills to write smart contracts, but also average people with no programming knowledge whatsoever, can just as easily start developing in natural languages like English. The implications for this should instantly be absolutely clear. iOlite is dissolving the existing technical learning boundaries, or more aptly put, as their slogan suggests: bridging the gaps.

The added beauty of this platform is that it is absolutely free to use, but encourages inter-collaboration of intermediate programmers and expert developers to benefit greatly in two ways: auditing the writing process of an author’s smart contract, and by developing

Suppose that a user desires to implement a smart contract that will allow her to lend money to her clients when they deposit a portion of gold into a new automated machine she is designing. Perhaps her machine is already capable with technology which can verify the gold’s purity, weight, etc. but she has no knowledge of how to program the technical rules in a smart contract required to safely lend the money itself. Thus far, the language’s base library has allowed her to smoothly write the bulk of her contract in general, but when she tries to include a “calculate_loan for gold_value” feature, the parser returns a window with multiple options. Because her feature is quite specific, the suggested options might vary. Base features are approved manually by iOlite Foundation developers, and are to be displayed in green to indicate safety/reliability, but perhaps, in this case, the only base expression available to her is a loan feature for banking use.

This is where the blockchain technology in iOlite begins to shine through. Because there will inevitably be an endless demand for niche-use features in a smart contract, contributors will be able to audit specifics in an author’s contract, and/or code new features to satisfy the needs of the market in general. In our running example, let us say that a contributor decides to design the “calculate_loan for gold_value” feature as they expect it could be used in more than just our author’s new machine. The resulting code is made as a commit candidate, then the third type of actor in the ecosystem, promoters, lock tokens on this contributor’s feature until it is approved for the staging process. When the threshold for locked tokens is adequately met,

Using iOlite’s beta-test proof-of-concept (Voxelurn running an early FAE,) parts of the contributor’s process can be illustrated robustly:

In the above image, we can analogize the design of a higher order feature composed of constituent DAL structures from a contributor’s perspective. For our author’s desired feature of “calculate_loan for gold_value,” the contributor must create an expression which will define a function that calculates an output dollar amount to be loaned. So for the analogy, the contributor will try to create a blank dollar which will generate a face value depending on the received gold’s worth. Already, the contributor comes across a tool for building a dollar much more efficiently, a “print money” feature. The flexible nature of FAE allows that this subcomponent may be an existing feature subject to use with fees already, or could be proposed for staging independently if it were not yet in the base library. Either way, it is optimal for the higher-order feature’s recipe, so it is utilized.

We can see that the sub-feature was efficient in creating the blank dollar, the analogy for the “calculate_loan for gold_value” feature, and it is now ready to be proposed for staging.

This now should hopefully begin to explain why initially our author was given a variety of options for her desired function. The parser may have detected constituent features related to her input expression, such as “loan,” which would now show why a suggestion for the mentioned “loan for banking” feature included in the base library appeared as an option. But other features that are not yet in the base library may appear too, this is in fact a key characteristic of staging. These options appear in yellow to indicate a bit of caution.

The interesting process that arises in staging is that a feature is not limited only to the smart contract it may have been initially designed for. Other users/authors may incorporate the feature into their own smart contracts where they potentially will pay fees to the contributor. This usage is an exceptional way to gauge popularity, especially in a competitive sense where differently structured features may be competing in optimization for the same solution. Whichever one becomes widespread the most, will eventually gain a manual review by the foundation members and be either rejected or approved into the base library. This not only stamps a seal of reliability and safety for the feature, but it also effectively

Let’s not forget about our user’s smart contract just yet, though. With this newly delivered feature, she can now put the finishing touches on her contract and put it to work. Because of her role as an author of the rest of the overall body of the smart contract, she is entitled to publish it with a price in iLT, available to businesses and clients if she so chooses, and any contributors which she used code of will also be compensated in use fees.

A bigger picture is now forming. iOlite is not only a powerful translation tool, but it is also an intelligence market. A market that cryptographically proves intellectual property.  The entry angle is justifiably focused on smart contracts, the need is urgent. The endless applications span from insurance underwriters, lawyers, financial services, businesses, automation, and so on. Arguably, iOlite as a collective macro-system is a knowledge generator, it inherently fosters the best features to win through market forces, making it an ideal model for finding truth. This has many possible future trajectories. As it grows, it would be very easy to imagine iOlite providing solutions for many more language-system problems, such as formal ones in mathematics, and maybe even bridging a gap between natural and formal definitions in fields like neuropsychology. A universal translator does not appear to be so science-fiction anymore…