XEL Project
  • XEL - community wiki
  • Linux - miner tutorial
  • Forging
  • offline-wallet
  • testing
    • ann
      • XEL December Update
      • original post : https://github.com/OrdinaryDude/elastic-core-maven/blob/master/UPD1.md
      • A New Release For XEL
    • articles
      • Safely Executing Untrusted Code
      • Debunked: You Are Not Investing
      • XEL's Payout/Payment Model
      • A Brief Introduction
      • Part 2: Broadcast to the Blockchain
      • Difference to Other Projects
      • Part 3: Storage and Iterations
      • Part 1: Your First XEL Program
      • Part 4: Using the Mining Software
    • tech
      • epl-language-notes
  • ePL Storage job
  • ePL Travelling Salesman
  • about-xeline
  • About (ePL)
  • xel-miner-guide
  • XEL - community wiki
  • To Do
  • xel-api-description
  • linux-xeline
  • XEL api
  • ePL – Advanced Tactics
  • Welcome to XEL!
  • MacOS - miner tutorial
  • Linux - tutorial
  • xel-kit-for-javascript
  • g-tnode-wallet
  • Windows - miner tutorial
  • linux-tutoria
  • ePL Sample
  • web-wallet
  • test
  • About Xel Miner
  • ePL – Programming
  • ePL – Submitting Tasks
  • support-wiki
  • xel-api
  • mac-os-xeline
  • ePL Simple job
  • windows-xeline
  • Start the xel miner
  • mac-os-tutorial
  • ePL Bitcoin Mining
  • windows-tutorial
Powered by GitBook
On this page

Was this helpful?

  1. testing
  2. articles

Safely Executing Untrusted Code

It has always been a golden rule: never run any code of untrusted sources on trusted systems. Even manual code checks do not guarantee that there is no hidden, obfuscated malicious section of code included waiting to attack your systems (would you believe it, if I told you that this program calculates PI?). However, also poorly programmed code, even though not malicious, can use up your system's resources and significantly eat away at the performance of your system.

Many other projects that rely on the execution of foreign code do that in a sandboxed environment. Such environments usually provide their storage space and an isolated memory block, which prevents potentially malicious code to eavesdrop on your data, extract sensitive information from other parts of your RAM, or alter your computer in an undesired way. We, however, do not believe this is a viable approach. Not only do you rely on the security of other third-party systems (any vulnerability they built into their product affect you as well) but also the management of resources (and resource allocation) is pretty complicated. I have seen projects in the past, that would not allow you to alter the computer's data but easily allowed for freezing the computer by, e.g., executing an infinite loop or using the computer's network connection to relay all sorts of (potentially illegal) data. We believe that the issue of safely executing foreign code can be solved more elegantly - without the need of one more additional layer and a potential source of error.

XEL's Programming Language

Our solution to the problems described above is an own programming language - ePL. With ePL, which was explicitly designed for the use on the XEL blockchain, we have managed to ensure safety on the fundamental design-level. It ensures both, safe execution of foreign code on the own computer and reliable verification of the computed results (which assures you that the results other people submit are valid). To dig a bit deeper: ePL is designed as an intermediate language with a radically reduced instruction set. While it comes with a variety of mathematical (and logical) operators and allows for modeling very complex control flows, it lacks any other features that could cause harm to your computer. For example, functions that might be used for accessing the user's hard drive, downloading files from the internet, or executing anything on the host system are not available. Also, due to an analysis on the logic level - these checks are performed for every program - it can be ensured that the programs do not contain any infinite loops or use excessive amounts of resources. While Turing complete languages typically suffer from the "decision problem" - the problem of deciding whether (and when) a program will terminate - our programming language ensures the termination of every program after a certain amount of instructions.

The design of ePL makes it just powerful enough to allow for the implementation of a wide variety of algorithms but yet limits it to safe operations only, guaranteeing that algorithms written in ePL can not eavesdrop on your data or show any other malicious and unwanted behavior. If this sounds too technical for you, picture it as a programming language which just does not have any functions that could even remotely cause any harm to the computer - no network access, no file access, no conditional loops, no gotos, ... just like a programmable calculator which is designed to carry out a particular set of harmless calculations only.

PreviousarticlesNextDebunked: You Are Not Investing

Last updated 6 years ago

Was this helpful?