DEV Community: Alex Dovzhanyn

Elixium: A Decentralized App Network Built for Developers

Alex Dovzhanyn — Sun, 04 Nov 2018 01:51:09 +0000

I just wanted to bring some attention to a project I've been working hard on for the past few months, and hopefully bring on board some new contributors who want to get their hands dirty. It's called Elixium. Elixium is a decentralized application network built for developers; its a Proof of Work blockchain that allows engineers to write programs that run on the chain.

Decentralized applications aren't a new idea -- other networks such as Ethereum or EOS offer smart contracting functionality that doubles as a platform for decentralized applications, but they have their own limitations which we'll talk about in a second. The way Elixium differs from Ethereum/EOS/Lisk is that we're aiming to be akin to AWS, except decentralized, along with offering privacy out of the box.

What we're aiming to solve

One of the biggest issues in the blockchain ecosystem right now is the high barrier to entry for engineers who want to use the technology, whether its to create a decentralized application or just to interface with the blockchain. This can be attributed to many different things, but the most pressing reason is that language support in the ecosystem is very poor. In order for an engineer to create a decentralized application or smart contract, they need to either learn a language that is specifically created for smart contracting or use a predetermined language that they might not already know. The fact of the matter is that learning a new language can take days or even weeks, and engineers that I've spoken to are very excited about blockchain but don't want to invest weeks of their time learning a new toolset for a system that might not exist in a few years (e.g. learning Solidity to create Ethereum dApps), since the ecosystem is so rapidly evolving.

Elixium mitigates this barrier to entry by employing language agnostic smart contracts -- decentralized applications that can be written in potentially any language. Engineers will no longer be tied down to learning a new language like Solidity or migrating to a language like Javascript, they'll be able to use their existing toolset and create decentralized applications with any language that compiles to WebAssembly. They'll be able to use their C, C++, Python, Go, and any other language they're already farmiliar with -- all they have to do is learn a new API to interact with the chain.

Elixium is built with a technology that focuses on fault tolerance and scalability. This technology is a programming language called Elixir, which is built using a language called Erlang.

But why does this matter?

Erlang powers the entire telecom industry. This is the language that supports the infrastructure of our mobile phone networks. It was built by a company called Ericcson in 1986 for the purposes of being distributed, fault tolerant, and to have support for uninterruptable applications. Erlang was reported to have been used in production systems with an uptime of 9 nines, which is a maximum downtime of 32 milliseconds per year. This is a great fit for blockchain, as it is a system that needs to be extremely fault tolerant and available.

Concurrency is at the core of the language - processes are cheap and you can run hundreds of thousands to even millions of processes easily. This allows for huge performance improvements and parallelization. Erlang has built in error containment and fault tolerance. It has a really cool feature called a Supervisor, which automatically restarts failed processes. Erlang also features hot code swapping functionality -- allowing the software to be updated without interrupting the program. This makes writing distributed applications easy.

Because of Erlang's large support for concurrency, Elixium is able to mitigate pain points in blockchain by massively parallelizing things like transaction processing. Whenever a new transaction comes in, it's cheap and easy to spin up a separate process to validate and relay that transaction.

Using hot code swapping, Elixium reduces friction from nodes whenever a new version is released. Rather than a maintainer of a node needing to take down that node, download a patch, run the update, and then start the node back up, maintainers can choose to have their nodes updated on the fly. This reduces the chances of forks happening on the chain whenever a new patch is released.

As a result of the fault tolerance built into Erlang, and by extension Elixir, Elixium is able to have self-healing nodes. If a node encounters an error during runtime, rather than crashing and waiting for the maintainer of the node to notice and restart the node, it is able to restart itself and not lose context of its current operations, which adds to the total uptime and security of the overall network.

Anonymous transactions

We're going to be the first (that I'm aware of) blockchain that strictly enforces zkSNARKS technology in it's core. Other networks default to insecure / non-anonymous transactions and some allow nodes to opt into secure transactions. Our approach is to only allow anonymous transactions via zero knowledge proofs -- it's part of our consensus mechanism. We're still researching this, but we're looking at using Hyrax, a zero knowledge protocol that doesn't need a trusted setup.

A few other goodies

Smooth token emission similar to the CryptoNote token emission algorithm
Memory-hardened PoW algorithm that discourages the usage of FPGA/ASICs
Journalized sharding (more info here)
TCP-layer zero knowledge peer authentication for secure communication

Where we are now

Right now, we're very early in our development phase, so it's a great time to get involved if you want to sway the direction of the project. We're completely open source and community driven, and we aim to continue being that way -- decentralized even within the development team. We don't yet have a whitepaper; a lot of project launch with nothing but a whitepaper, we wanted to have an MVP done before writing a whitepaper to allow the technology to speak for itself, and have the whitepaper be supplemental to the actual system, not vice-versa.

The website isn't fully done, but I'll link it here as it has some useful links.

GitHub
Website (P.S. as soon as you contribute to the core, your name + photo is added to the team section of the website)
Telegram Group (This is where pretty much all of the development discussion is)
Twitter
Reddit

Building a Blockchain - What I've learned over the past few months

Alex Dovzhanyn — Sun, 12 Aug 2018 19:17:18 +0000

7 months ago, when I first embarked on the journey of creating a new blockchain, I was inspired by the thought of changing the internet -- of being on the front lines of innovation, developing bleeding-edge technology, and pushing the boundaries of how we interact. I was deeply intrigued by blockchain technology and it's ability to change the world for the better, to make the internet into the decentralized and uncontrolled networking system that it was meant to be.

I noticed a few gaps in the blockchain community at the time, for example: all cryptocurrencies/blockchains fit into a maximum of 2 of the following categories:

Fast
Anonymous
More than just internet money

A blockchain that was both fast and anonymous was meant to be a currency, an anonymous blockchain that was more than just internet money was not fast, etc. As an engineer, I thought to myself, "why not combine all three?". If we're going to build a decentralized internet, we can't settle for something that doesn't satisfy all of the things we do on the internet today: shop, use web apps, and manage banking accounts (hopefully securely). This led me to creating Elixium (@ElixiumNetwork, /r/elixium): a fast, anonymous, and scriptable blockchain network.

Elixium allows developers to create decentralized applications written in Javascript, removing the barrier of needing to learn a new language in order to write dApps.

Here are a few thing I learned in the process:

1. Distributed Computing is Hard

Finding a way to allow people to write applications in javascript, and making it fair to the miners is a difficult problem to solve. Javascript is a turing-complete language, which means it is impossible to parse through it's code and determine whether or not it will run forever (e.g. contains an infinite loop). I spent hours trying to figure out a good way to do this, and finally came up with the following solution, based on Ethereum's model:

Parse the javascript into it's abstract syntax tree (AST) representation
Sanitize the javascript, making sure all variables are namespaced, in order to minimize interference with any other code that would be interacting with the contract
Calculate costs based on the computational complexity of a line of code.

This allows miners/nodes on the network who are running the code of the contract to charge a small fee to the developer of the contract for running the code (similar to how hosting services charge money to host your website, or how AWS charges for usage of their servers).

This also solved the issue of infinite loops: eventually the funder of the contract would run out of funds to run it, and the contract execution would stop (even if there was an infinite loop)

2. Networking is really cool

I used to take the convenience of HTTP for granted, but after writing a communication protocol on top of TCP that fit the specific needs of the Elixium network, I realized how crucial it is to understand the way that internet communication works. The tentatively-named Ghost protocol is built on top of TCP and uses an SRP protocol layer to establish a handshake between peers, allowing for end-to-end encryption.

Writing a communication protocol isn't actually too hard - you all should give it a try!

3. Nothing is set in stone

Since blockchain is such a new field of technology, there really aren't that many standards set in place, as you might expect there to be if you come from a web development background. In web development, there's usually one or two different ways of accomplishing a goal that have been standardized, and those standards are relatively easy to spot, e.g. using bcrypt for password authentication, or using Ajax to make XHR requests, or manipulating DOM elements.

In the world of blockchain, it's a lot more open. At first, this felt weird, because I was used to knowing what the "right" way of doing something was, and if I couldn't find the "right" way, it felt weird to me. Slowly I realized that there is no tried and true way of doing many blockchain related things, like which hashing algorithms to use, the proper way to set up a consensus algorithm, or even how to store data! This allows you to be really creative in the way you solve problems, and although it first felt taboo, it's actually really liberating.

Oh, and by the way, Elixium is open source and looking for contributors, so hop on GitHub and help us make a better internet!

Recursion For Beginners

Alex Dovzhanyn — Mon, 30 Jul 2018 18:43:46 +0000

One topic that stumped me as a beginner programmer was the concept of recursion. It’s something that seems to never be used outside of programming, and it’s advantages aren’t quite obvious, making it something not-too-easy to understand. This is an attempt to effectively explain recursion to anyone who isn’t sure what it is, how it works, or why it’s useful.

What is Recursion?
According to Webster Dictionary, recursion is:

“a computer programming technique involving the use of a procedure, subroutine, function, or algorithm that calls itself one or more times until a specified condition is met at which time the rest of each repetition is processed from the last one called to the first”

But what does that even mean? We already know it’s a computer programming technique, but under what conditions would you want a function to call itself?

Basically, recursion is the concept of having a function call itself until it has done whatever it needs to. This is kind of like a loop (and some languages actually use recursion AS their loops under the hood), but the key difference is that loops (iteration) work by explicitly specifying a repetition structure, whereas recursion achieves repetition by continuous method calls. Consider the following task:

Create a method that takes any two numbers as parameters and runs the fibonacci sequence algorithm on them 100 times, and displays the output for each step.

Iteratively, you may do so like this:

const fib = (a, b) => {   // Create the method
  counter = 0              // Instantiate a counter
  while(counter < 100) {     // Loop until the counter reaches 99 
    sum = a + b
    console.log(sum)
    a = b                  // Reassign the variables for the next iteration
    b = sum
    counter++
  }
}

fib(4,5);                   // Call the function

This gives you the desired results, and works fine. Recursively, though, it would look something like:

fib = (a, b, counter = 0) => { // Create the method
  if (counter > 100) return // Check exit condition
  counter++
  console.log(a + b)
  return fib(b, a + b, counter) // Call itself again if exit condition isnt met
}

fib(4,5)

As you can see, they both give the same results, but the recursion is slightly shorter and easier to read. Recursion allows for management of exponential growth. While recursion is useful in many cases, there are also cases when it is better to solve the problem iteratively. Recursion is usually more memory intensive, so it may not be the best option for solving problems that require minimal memory usage.

Working With Webhooks in Development

Alex Dovzhanyn — Thu, 26 Jul 2018 21:47:45 +0000

I often find myself needing to integrate with an API or external service when building apps or new features. Often enough, I need to be able to fetch information in (almost) real time. Services like MailChimp and PayPal offer webhooks, which is basically a fancy way of describing and external POST request to your server (Click here if you aren’t familiar with HTTP verbs). Anyone who’s worked with webhooks in a development environment knows it’s quite a pain to work with them if you don't have hosting set up, because you can’t just pass in your localhost address to these services. Localhost pretty much just translates to 127.0.0.1, which is (generally) every computers home IP; telling an API to POST to localhost:3000/your_hook_path literally just tells it to post to itself (and usually APIs won’t let you enter localhost as a URL). You can see how this puts you in an awkward position during development and testing.

Ngrok: The Best Thing Since Sliced Bread

Ngrok is a really great tool to solve this problem, and I personally love the tool as a whole (it works with more than just webhooks). Basically, ngrok sets up a URL that routes any incoming requests to a port of your choice, which makes it really useful when working with webhooks. Setting up ngrok is super fast, too. Just download it here, cd into the directory where you installed it, and run ./ngrok http 3000, replacing the 3000 with whatever port you want to expose. If all goes well (and it probably will) ngrok will generate a HTTP and HTTPS URL that forwards to your localhost. All you have to do now is provide the API webhook with the generated URL, and voila! You’ve got a working webhook listener in your development environment. It’s important to note that ngrok will generate a new set of URLs every time you restart the client, so you will need to swap out the URL in the APIs webhook. I also love using ngrok for demoing work while I’m developing. That way, anyone can see the current status of the app/website I’m working on without me having to set up hosting, and I can avoid deploying until it’s actually necessary. It’s also great for testing your website across multiple devices/browsers, because you can connect from pretty much anything.

Everyone Loves Ngrok!

Don’t just take my word for it, here are some tweets from people who love ngrok:

“so ngrok.com is basically the greatest thing ever.“
— @philadams

“#ngrok is a dream for testing localhost with remote APIs!“
— @davejlong

“#ngrok has got to be the easiest local tunnel solution I’ve ever used.“
— @thecodeboss

… and there’s actually quite a bit more love.

Rydux - A Redux store for your ruby application

Alex Dovzhanyn — Wed, 27 Jun 2018 15:04:21 +0000

Hey all, just wanted to write this post to let you know about a small ruby gem I've created, Rydux. This gem allows you to decouple the state from your logic in your application, and implements a more functional paradigm to ruby programming. You can check it out here.

To use the gem, require it somewhere in the root of your application (or somewhere the store will be accessible everywhere you need it). Next, create some reducers in your application, you can place them anywhere, but a reducers/ directory is recommended. A sample reducer looks something like this:

  # reducers/user_reducer.rb

  class UserReducer < Rydux::Reducer

    # Your reducer MUST have a map_state function in order to do anything.
    def self.map_state(action, state = {})
      case action[:type]
      when 'SOME_RANDOM_ACTION' # You can add as many actions here as you'd like
        state.merge(some_random_data: true)
      when 'APPEND_PAYLOAD'
        state.merge(action[:payload])
      else
        state
      end
    end

  end

Create a store somewhere easily accessible in your application:

    require 'reducers/user_reducer'

    # The key passed into .new here is the key at which this value
    # will be stored in the state. E.g. { user: whatever_user_state }
    Store = Rydux::Store.new(user: UserReducer)

Have something subscribe to the store:

    class MyClass
      def initialize
        Store.subscribe(self)
      end

      # Every instance that subscribes to the store will
      # get this state_changed method called whenever the state
      # in the store changes. Do whatever you want with your state here.
      def state_changed(state)
        # ...
      end
    end

To update the store with new data, you can dispatch actions, like so:

    Store.dispatch(type: 'SOME_RANDOM_ACTION')

Putting it all together:

require 'rydux'

class UserReducer < Rydux::Reducer
  @@initial_state = { name: 'Alex', age: 20 }

  def self.map_state(action, state = @@initial_state)
    case action[:type]
    when 'CHANGE_USER_NAME'
      state.merge(name: action[:payload][:name])
    else
      state
    end
  end

end

Store = Rydux::Store.new(user: UserReducer)

class Friend
  def initialize
    Store.subscribe(self)
    @users_name = Store.state.user.name
  end

  def state_changed(state)
    @users_name = state.user.name
  end

  def greet_user
    puts "Hello, #{@users_name}"
  end
end

# Create a new friend (this will subscribe it to the store)
friend = Friend.new
friend.greet_user #=> Hello, Alex

# Change a value in the store
Store.dispatch(type: 'CHANGE_USER_NAME', payload: { name: 'Mike' })
friend.greet_user #=> Hello, Mike