1 Glow FAQ

1.1 How do I ... ?

For all questions about practical steps, see our How-To guide or our reference manual.

1.2 Is Glow a platform? A language? Both?

Both! Glow is a DSL, a domain-specific language. It is also a platform with libraries. In the long-run, we might name these two differently to avoid confusion.

1.3 Can you quickly sum-up the benefits of Glow?

1. Writing a DApp that is 10x safer for 1/10th the effort than using say Solidity + JavaScript.

2. Writing it once, and having it work everywhere, and not just on EVM blockchains. You don’t have to guess where the liquidity will be and then bank on a technology that only works on one network or family of networks.

3. Generating not just the "smart contract", but the client and server code that exactly matches it for each participant.

4. Having a chance at formal methods.

1.4 What blockchains does Glow run on?

Glow currently runs on blockchains using the Ethereum Virtual Machine (EVM). These blockchains of course include Ethereum and Ethereum Classic, but also many other blockchains, including but not limited to Binance Coin, VeChain, TRON, etc.

However, the default blockchain used by Glow today is the Cardano EVM Devnet. That blockchain is the developer network in preparation for the launch of the Cardano KEVM side-chain. This is the blockchain against which we currently run our tests. Glow can easily be made to run on any blockchain that supports the EVM, but we are not currently testing against them, though MuKn will gladly sell you contracts for such maintenance service.

Glow will also support Plutus as a backend when it launches on the Cardano network. And Glow in the future can potentially run your applications identically on any and all blockchains on which you can write smart contracts. If you want Glow to support a particular blockchain, MuKn will gladly help make it happen.

1.4.1 Does Glow work on the EVM?

Yes, the EVM is the primary target for Glow at the moment, and Glow should run on all EVM blockchains.

If you’re worried because you saw an announcement about Glow being launched on Cardano, fear not: we will support Plutus on Cardano, but the chain we did launch on previously was a devnet for the upcoming Cardano KEVM sidechain.

1.4.2 Do you directly generate EVM bytecode?

Yes, we directly generate EVM bytecodes.

An early prototype in 2019 for what would later become Glow did compile to Solidity, but we found that the Solidity compiler was not robust enough to handle what we were throwing at it, except in the simplest of cases. Our compiler is currently lacking in micro-optimizations, but we’re more than making it up with macro-optimizations instead: the code generated by Solidity is bad enough that micro-optimizations make no big difference, and the ABI, calling conventions and encodings used by Solidity are so inefficient and costly that we can easily do better, with plenty of ideas how to do even better.

1.5 What will it take to support another blockchain?

That depends on the blockchain.

1.5.1 What will it take to support another EVM blockchain?

For most EVM blockchains, all it takes for Glow to support it might be changing a few lines in a configuration file.

Some blockchains that sport their own extensions to the EVM, or have serious restrictions on usage of a not-so-compatible EVM, may require a month of work, maybe two.

1.5.2 What will it take to support another smart-contract blockchain?

For most non-EVM yet smart-contract-capable blockchains, such as PolkaDot, EOS, Nervos, Algorand, Tezos, etc., it should take about two to three months of work for Glow to support it.

We have to set up the Blockchain’s development environment, learn the details of their virtual machine and transaction APIs, make experiments to determine their precise semantics, determine how it does or does not fit the expectations of Glow, and as we do, write suitable backends for Glow’s smart contract compiler and client runtime. This is full time work for two people.

And then, it may take more time and effort to add optimizations, support new features, prevent the code-base from bitrotting, etc.

MuKn will happily sell development and maintenance contracts to blockchain companies and foundations to ensure that Glow keeps running smoothly on their platform of choice.

1.5.3 What will it take to support Bitcoin?

Bitcoin was never designed for smart contracts, and will require much more resources to support.

Bitcoin script and the size limits on its usage provide a hostile environment to general smart contracts. What more, BTC is missing some opcodes that its network explicitly disabled, and some more opcodes of which it explicitly rejected the adoption. This makes BTC in particular an even more challenging target platform for Glow than the other forks and clones of Bitcoin that have adopted those missing opcodes. (Adoption of these opcodes was even one of the notable points of contention that led to the BCH fork; BCH leaders do actively support “covenants”).

In the end, it will take roughly 6 months of work to initially support BCH and other similar contract-ready Bitcoin forks and clones. Indeed, in addition to work required on any blockchain, we will need to work around the quirks and limitations of the platform, and add extra optimization passes just to fit in the extremely limited transaction size limits. Furthermore, the ongoing development and maintenance costs will be larger than for more modern blockchains with virtual machines designed for contracts. But it is all possible, and we wrote experiments to confirm that it is possible.

By contrast, it will take at least double the time and effort to initially support BTC and similarly contract-hostile Bitcoin forks and clones. Indeed, a lot of additional tricks are required to overcome BTC’s limitations, and these tricks may involve dividing contracts in even more sub-contracts (e.g. one per bit of the output) and transactions into even more transactions (e.g. many partial transactions to emulate the missing opcodes the hard way). In the end, the fees required to execute such contracts might be prohibitive, especially at the levels currently seen on Bitcoin. Even more elaborate optimizations might be necessary just to keep these fees affordable for the highest value contracts. The amount of engineering efforts required, combined with the economic limits of its applicability, put BTC support low on our priority list. It is definitely not a juicy low-hanging fruit. But we will gladly work on this support if some Bitcoin whales fund us.

1.6 What is the product of Glow?

Glow produces interactions. For instance, the closing of a sale; a optional future purchase of some digitalized commodity; the delivery of some physical good all along a supply chain; an online auction; a barter swap between two baskets of digital assets; an insurance contract; a loan and its repayment; a game tournament; a sponsorship contract; etc.

No file as such is created along the way, though many entries in blockchains and local databases are generated.

1.7 What does a typical Glow interaction look like?

First, two (or more) participants create an agreement.

After they precisely agree on all the terms of the agreement, Glow generates the code for each participant to execute the agreement, which they each run on their local machines.

The interaction code in turn may create or use smart contracts on agreed-upon blockchains to hold each other accountable for doing their part of the agreement.

1.7.1 What does reaching an agreement look like?

Often, one participant is a “merchant” or “market-maker” whose website or servers publicly offers deals for other people to take. The terms of the agreement are listed, and all the other participants have to do is fill in their name and address and the desired quantity (within allowed limits), and sign the offer before it expires.

In other cases, two participants try to reach a private agreement, wherein they exchange tentative terms for a deal, making offers and counter-offers, until the terms offered by one party are accepted by the other party.

In either case, this negotiation happens “offchain”. Each participant’s client or server software helps them browse the market or publish offers, seek partners and negotiate terms, etc. The participant’s software will also filter out undesired sollicitations, reject offers with obviously unacceptable terms, assist participants in defining and maintaining parameter limits, and help them optimize their yield, profits, risks, etc.

1.7.2 What does an agreement execution look like?

Once an agreement was reached, its execution takes the form of steps each taken by a participant or the other.

For instance, in an asset swap, a first participant puts his basket of assets in escrow, then the other participants puts theirs, and when they all did, the assets are distributed to their new owners according the agreed upon formulas. There is one step by participant, and the last step includes the distribution. Between two participants, that’s two steps.

In a futures contract, some assets are escrowed by each participant in the beginning (one step per participant); then, at some due date, one participant may exercise an option (one step, or no step if he waits until the option expires); finally, the contract is settled. Between two participants, that’s typically three or four steps.

In a game tournament, participants initially deposit their stakes (one step per participant); then there will be at least one step by one participant at each “turn” of each game, sometimes many or all participants contributing steps to complete each “turn” depending on the game, and when a game is complete, another game may start, until the tournament reaches its conclusion, and prizes are distributed per the agreed-upon formula. There can easily be hundreds or thousands of steps.

1.7.3 What does holding accountable look like?

Agreements include promises by each participant to act according to the interaction’s rules. At the beginning of the interaction, one or many smart contracts are created or used on some blockchain, that encodes the rules of the interaction. Each participant who has any opportunity to fail to follow the rules in the future will typically deposit some collateral assets in escrow, in addition to the main assets at stake, to hold them accountable should they defect.

When a participant acts outside of the parameters, or fails to act in a timely fashion within those parameters, the other participants can invoke the smart contracts as recourse; the assets escrowed as collateral by the defecting participant will be distributed to the other participants to make them whole for any loss, according to the agreed upon formula.

1.8 What can I do with Glow?

Glow is rapidly acquiring more features, enabling users to enter more elaborate interactions.

When Glow was initially launched, it could only handle interactions between two participants trading a single asset class in a finite number of steps. Furthermore, it only executing interactions in "direct-style": a smart contract would oversea the execution of each and every step of the interaction.

Please inquire on our Discord channel (invite) for the current precise status of Glow and whether it can handle your desired interactions at any given time.

1.8.1 What interactions are included in Glow’s standard library?

Glow’s standard library at launch included the following contracts:

• "Buy Signature", a general atomic closing contract for a sale, wherein a Buyer purchases the signature of a specific document by a Seller. The document can be a legal document, a transaction that completes a transfer on another blockchain, an digital certificate of some sort, etc.

• "Coin Flip", based on a general technique to produce mutually random numbers, that can be reused in the many situations where such mutually random numbers are useful.

• "Rock Paper Scissors", a simple game that illustrates more elaborate interactions with escrowed collaterals.

We keep adding more contracts to our library as we extend the language. Please inquire on our Discord channel (invite) for the latest status.

1.8.2 Is there a Glow library for NFTs? for ERC20 contracts?

We are currently working to add support for tokenized assets (whether fungible or not) natively to Glow. This means that you will be able to manipulate those assets explicitly as part of the language, rather than as function calls that implicitly transfer tokens. This also means that as we develop formal methods to prove correctness of interactions, these proofs will be able to directly account for value of those assets.

1.9 What are Generalized State Channels?

Generalized State Channels are a generalization of the State Channels as made famous by the Bitcoin Lightning Network. While the simple State Channels of the Lightning Network only allow for simple one-way payments, Generalized State Channels allow for arbitrary smart contracts to be executed via State Channels.

State Channels and Generalized State Channels allow for an unlimited number of fast and cheap transactions between a small number of cooperating participants who have created those special contracts on the blockchain, even when transactions on the blockchain itself may be limited in volume and incur high transaction fees.

The downside of State Channels and Generalized State Channels is that if one participant stops cooperating for whatever reason, it may take a relatively long time and high fees (typically a week and at 2021 prices tens of dollars maybe hundreds) for other participants to properly close the channel and recover funds.

Glow will support Generalized State Channels, and do so better than previous solutions: previous solutions required you to rewrite your agreement multiple times, in multiple languages to properly execute it and display its status to the user: once in Solidity, then once in Go and/or JavaScript for each of the participants. Any mistake in the translation, any discrepancy between those multiple versions of the code, and some participants would risk losing all their assets at stake. This makes using previous Generalized State Channel solutions extremely complex and risky. Glow by contrast automatically generates all variants of all code for all participants from a single simple specification of the interaction, removing the complexity and the risk associated to using Generalized State Channels.

1.10 Does Glow compile files?

1.10.1 Does Glow compile DApps into smart contracts?

Yes, as it executes DApp interactions, Glow compiles their specifications on the fly into suitable blockchain smart contracts. It does not at any point create a file for these smart contracts: there is no point whatsoever in files that only risk being lost or corrupted. Instead, it directly creates a contract on the blockchain when needed, or reuses an existing blockchain contract when possible.

Typically, the on-chain smart contract is created or invoked as the first participant as the first step in executing the agreement. If a new contract was created, it may typically be destroyed by the last participant in the last step of the agreement execution. In between the first and last steps, the Glow clients for each participant will handle all interaction with the blockchain and other participants, so you don’t have to interact with them yourself, which is a very error-prone and completely unforgiving yet safety-critical activity.

1.10.2 Does Glow compile DApps into client programs?

As it executes interactions, Glow also runs every step on each participant’s local computer. This part is compiled to a virtual machine then interpreted as virtual machine code. So there are both a compiler and an interpreter involved.

Certainly, we could possibly make the participant-side code 10x to 100x faster by compiling it further rather than interpreting code. But there is little economic incentive for that: running an interaction at all means that you’re paying or ready to pay blockchain fees for that, and these are millions (and now billions?) of times more expensive than it costs to run the code on the participants’ machines. Spending our time optimizing client-side evaluation is completely worthless when instead there are so many useful features to add to the language.

There may come a time in some future when the language grows to support more complex computations on the participants’ computers. At that point, client-side optimization may become a sensible activity; but that is not now, and probably not in the next year or two (as of 2021).

1.10.3 Does Glow generate any file on a participant’s machine?

Yes, on each participant’s computer, Glow creates, maintains and uses various configuration files, as well as a small database and log files, to track the identities managed for the user, the contacts known to the user, and the progress of the interactions the user is partaking in, so as to ensure they are conducted to completion.

None of that corresponds to generating compiled files from source code (compilation is done in-memory), but it does count as generating and using files on the participants’ machines.

1.10.4 How are you generating JavaScript?

We use Gerbil Scheme as our main programming language, which compiles to Gambit Scheme, which has a JavaScript backend. We can thus automatically generate JavaScript for all our needs.

We do not use ReScript or TypeScript, though the language Glow itself sometimes reuses good ideas from their syntax and semantics. We do manually write some amount of JavaScript where needed to interface between our code and other people’s code.

1.11 Do I have to install other languages or modules to use Glow?

When you install Glow according to our instructions, all the dependencies you need are also installed with it.

In the near future, the dependencies will also include node.js, yarn, and a few JavaScript libraries used by our user interface.

In a further future, Glow will produce for end-users a single JavaScript file that will run directly on your browser with no dependencies.

1.12 Will Glow allow me to make a full DApp from scratch?

Ultimately, you will be able to use the Glow language to build all the parts of a DApp that touch the blockchain. Furthermore, the Glow compiler will automatically generate API descriptions for each entry point of those DApps, from which you will be able to generate API functions on the programming language of your choice.

But Glow is not and will not be a substitute for a general-purpose programming language for all the other parts of your application that do not touch the blockchain: fulfilling orders, managing inventory, computing rates, making economic models or physics engines, offering a shopping interface to end-users, or a management interface to team members, etc.—these are tasks that you will keep developing in your programming language or low-code platform of choice. MuKn will help you expose the functionality of Glow to your favorite platform if it doesn’t do it yet.

1.13 Will the .glow files I write today be compatible with the next versions of Glow?

We will do our best so your Glow applications keep working as we evolve our language, or to offer you a simple way to automatically update your programs so they work with the next version of Glow.

To ensure that any problem you have is handled in a timely fashion, be sure to either contribute your application to the community, or have a maintenance contract with MuKn to keep it running at all times.

1.13.1 Will your contracts be certified by Etherscan or otherwise self-certifying?

Etherscan provides verification services, wherein you can compare a binary contract as created on-chain to what the contract is supposed to be if it were indeed compiled from the declared source code with the declared compiler and declared parameters. This service kind of makes sense for those who use a language such as Solidity. then again, one must beware that Etherscan is itself a centralized authority.

But this workflow does not make sense to us. Instead, the Glow execution environment directly verifies the contracts it deals with. Glow requires participants to already have shared, off-chain, all the interaction source code they rely on, before they even begin to execute the interaction on-chain. The Glow client will plainly refuse to participate in any interaction that it cannot verify itself, without the need of any centralized authority.

Of course, you must make sure to certify your Glow client itself. If possible, you should have Glow audited by multiple suitable parties you trust, and only use versions that exactly match the one used by auditors, within the parameters recommended by those auditors. You can, of course, choose to trust or not trust each of the previous public opinions of auditors already paid by other people.

But that is no different from having to certify the combination of the Solidity source code used by a contract, Solidity compiler used to compile it, the "wallet" or "DApp" interface you use to interact with it, the "browser" on top of which you use these interface, the "operating system" on top of which the browser runs, the "hardware design and implementation" under that operating system, etc. You should not hold the components used by the competitors of Glow to a lower (or higher) standard than you hold Glow itself. But at least, in the code audit wars, Glow has much fewer lines of code to audit.

1.14 Is Glow Free Software?

Yes, Glow is and will forever remain Free Software, Open Source Software, or however you like to call it: everyone is free to copy, use, modify and redistribute Glow. Indeed, we believe this is an essential feature of a decentralized system that anyone should be able to see and audit, use and adapt, to fix and improve its code. Without these freedoms, it is impossible to trust the code as an ongoing system to use and keep using. Do not trust any software that claims to be decentralized yet isn’t Free Software.

Now, Glow has so far been developed by US-based company Mutual Knowledge Systems, Inc., also known as MuKn (pronounced “Moon”). We will gladly sell our services to improve Glow, help you use and deploy it; and we will also gladly sell our services to help you integrate it to your proprietary systems or to your software systems that you keep as trade secrets.

1.15 Is Glow Turing-Complete?

No, Glow is not Turing-Complete at this point.

We do see value in being able to express more elaborate computations, but we value safety over versatility. Thus, we won’t compromise on safety, and we will instead enable more advanced formal methods so you can keep proving your DApps correct as they get more elaborate. So while we will eventually reach a point when you can express arbitrary computations in Glow, along the way we will keep ensuring that Glow is and remains at any moment the best environment to develop safe DApps.