Why the blockchain?
Unless you just woke up from prolonged hibernation under Artic ice crust, you cannot miss the hype around blockchains and their related coins. If you are new to cryptocurrencies and blockchains, let me give you the simple bird view on that: speculation on cryptocurrencies is currently very high, but whether it is a bubble or not, bursting soon or never, is not really relevant. The important part, shadowed by the coins market hype, is that the blockchain technologies are a new infrastructure that should help solve many issues we have. It is a missing piece that we need in order to rebalance the modern Internet landscape, and bring back the decentralization that was once promised in the early Internet days.
Though, the impact of such disruptive change goes way beyond just Internet infrastructure (for example, IPFS or Storj), it has the potential to reshape many industries (see the Brave browser and its Basic Attention Token, bringing a saner alternative to online advertisement) and human activities, including in our daily lives. We are currently still just seeing the first generation of blockchains. Those pioneers have inefficiencies, like scalability and power consumption issues, though, after following and studying the evolution of blockchains during a year, I am now confident enough that those issues will be solved in a not-too-distant future by the next wave of blockchains (or upgraded versions of existing ones). For example, zero-knowledge proof and especially the non-interactive variant are really impressive and promising approaches.
So, how does Red fit there?
As Red aims to be a fullstack programming solution, we naturally look at what are the potential next big platforms we should support. Since last year, we are watching and studying the various blockchains, especially focusing on the ones supporting smart contracts, Ethereum being the leading chain in that domain. Basically, it is like a distributed computer, where you can run arbitrary sandboxed code, using the distributed ledger as its database. There are a few programming languages which can be used to implement those smart contracts, but Solidity is the default one now for such tasks. If you are a Red follower, you know how much we care about simplicity and efficiency in our programming tools. Well, those concerns do not seem to be shared by people who created the existing tools for smart contracts coding and testing. Let's put it bluntly, the current state is a nightmare. It takes several hours, up to a full day to just figure out and set up a development environment the first time, even for a senior developer. The sheer complexity in such toolchains is really high. The Remix initiative is still young, but it is a lifesaver compared to other existing toolchains. Still, you have to put up with a language that has many questionable design choices, for coding contracts which could handle billions of dollars worth of assets. Guess what happens under such conditions.
So, there is a huge need for a better, much simpler and safer contract development tool. We know that Red can deliver such solution, because that's our fight and our mission since the first release of Rebol 20 years ago. Still, people who work with me know how skeptical I am. So it took me several months of studying and discussions to figure out where and how Red could help in that domain.
Why now?
We are at an early point of a new revolution.We do know that much better development tools are needed, and the current offer is poor and disappointing to say the least. We know that we can provide a great solution based on Red, in an acceptable timeframe. This is an amazing opportunity, like we haven't seen since late 90's and the rise of the world wide web. This is our time now.
So this is what we will build, in a new branch of the Red project:
Red/C3
A new Red dialect (DSL) whose code-name is Red/CCC (Cross Chain Code) or just Red/C3, for smart contracts programming. Such dialect will compile to the Ethereum VM (EVM) bytecode directly as first target, and more backends will be added later to support other chains, like NEO. We are at the design stage, the first alpha (prototype) is planned for end of Q1 2018. Our current design involves a combination of two small languages:
- A very high-level layer: a symbolic and highly declarative language with restricted computing semantics and restricted control flow (turing-incomplete), reading mostly like natural language (compared to mainstream languages). Coarse-grained code produced at this level by the compiler will exhibit higher safety, close to the level provided by templates, while still providing much greater flexibility. An intelligent visual program builder will also be considered for pre-generating such code.
- A lower-level layer: a general-purpose, statically typed, subset of Red language.
Moreover, for testing such contracts, we plan to create:
- a simulator for the EVM (and later for other chains VM) coded in Red/System for fast performances.
- a generative testing environment, for auto-testing user contracts extensively in addition to manually written tests using a simple testing framework we will provide too.
- a GUI interface to handle all that in an easy way, without requiring deep knowledge of the blockchain infrastructure.
The toolchain will be an extension of the current Red toolchain, so it will be a standalone binary of 1-2MB.
Smart contracts are used to power what is called Decentralized Apps (Dapps)-- Basically a user-facing application operating on blockchains through smart contracts. Currently such Dapps are built using web stacks, but still need to connect to a blockchain node in order to interact with it. Light nodes could help solve that, but they break the decentralization model. So, in order to facilitate the deployment of the required blockchain nodes, such apps are often wrapped in a standalone native installer using an Electron framework. This results in big downloads (50-150MB) and big memory usages inherent to web stacks.
The Red stack, with its ~1MB runtime (~300KB if compressed) can provide a much better alternative, and Red GUI capabilities can lower drastically the entrance barrier and costs for coding apps and Dapps. In order to achieve that, we need to add a blockchain node connector in our runtime library, preferably wrapping a node in C library form, though using JSON-RPC is also an option.
For old Rebolers, maybe you remember Rebol/IOS in early 2000's, for handling the X-Internet? Well, guess what? Carl was right all along (as usual). ;-) You can look at the Red Dapps as a modern blockchain-powered incarnation of that concept!
What about the existing Red roadmap?
The Red core language development continues with the same roadmap, we are just delaying a bit the 0.6.4 and 0.6.5 releases, in order to pass the big wave of changes in the incoming weeks. In order to achieve that, while opening a new branch of development, we need to grow bigger and structure the whole thing differently. Here are the plans to move the whole project to the next stage:
Red Foundation
We were thinking about that since last year, but now is the right time to do it for many reasons. We need a dedicated organization to handle the community and contributors' efforts for the work on Red core language. We also have plans for business activities, and it would be easier to separate the teams working on the open-source project and the ones working on commercial products and services. It is not an unseen set up, the Clojure project structured itself in a similar way.
So, we have filed an application to set up a Red Foundation in France, and will transfer to it the rights and governance for the open source parts of Red. The managers of that structure will be: Gregg Irwin, Peter W A Wood, François Jouen and myself, for starting. The foundation has a complex job and will require resources to operate, hence:
Red community 2.0: RCT token
We are embracing the blockchain philosophy fully and will empower the Red users and community using a decentralized organization (DAO), supported by a new ERC20 token called Red Community Token (RCT). There is no other programming language or tool that I have heard of, attempting to move their existing community to a DAO, so we will be exploring uncharted territories there, and setting an example for others to follow. The foundation will be setting up the rules with the help of the community, for the usages of the RCT token. Some of the target usages for the token holders, will include:
- voting rights: influence the Red roadmap, vote for features and issue tickets.
- tipping: useful chat posts, code contributions, learning materials providers, etc.
- intra-community cryptoeconomics (or rather tokenomics): selling/buying services from other community members (coding tasks, consulting, learning help, bug fixing, decentralized gaming, etc.)
- paid Dapps, or in-app purchases.
In addition to that, the foundation will hold a significant amount of RCT, which will be used for rewarding:
- code contributions
- Red-related online learning or presenting materials (blog, documentations, etc.)
- promotional actions (presenting Red at a conference)
- any other actions that will help spread Red and make the community grow up.
There will be an initial distribution of RCT tokens to the existing Red contributors (once the foundation defines the rules and allocation amounts), that will retro-actively cover existing contributions (like merged PR, tickets resulting in code changes, past donations, etc.).
Last but not least, the RCT might be used in the future as a gas token, to pay for cross-chain different gas currencies, or to power a future Red's own blockchain.
Those are just scratching the surface of the possibilities that such token and DAO (powered by smart contracts) could open. This gives you an idea of the disruptive potential of blockchains, when rightly used. It is not yet clear how far we can go into the decentralized model, it is something we will explore all together (we'll set up dedicated chat rooms on Gitter and other sites for that).
This will be our greatest challenge, but I trust we have enough brain power in the Red foundation and community to figure out the best rules for a healthy organization.
Initial coin offering
In order to kickstart the RCT token, and fund all the resources needed to accomplish the above tasks and roadmap, we need to raise some money. Initial Coin Offering (ICO) are the new way to achieve that. I have been reluctant to do that for a while, given how young and controversial it can be (the amount of scams in that domain is really high), but after studying many other ICO, I am convinced now that this is not just a short-lived fad, but a real new model to fund projects, and especially open-source projects related to blockchains.
We have produced a whitepaper earlier this year in October (co-authored by Tamas Herman and myself), to describe with more details and context what we are building. We will release it publicly in a few days.
The ICO itself should be held in early January 2018, starting with an angel round, then pre-sale and open rounds following right after. A new website will be available in a few days, giving the full information required for the ICO.
The ICO should provide us with enough funds to cover all the needs for this ambitious roadmap. A job list will be available after it, as we hope to hire the best profiles from the Red community, so update your CV and clean-up the source code of your Red apps. ;-)
Final words
These are intense and exciting days for us and the Red community, I wish you all a Merry Christmas, and have a good beer, maybe someday you'll pay it on your smartphone with a Red Dapp powered by RCT tokens. ;-)
Cheers!
