Scaling without gimmicks

From 1997–2007 the series Stargate SG-1 chronicled the experiences of a team of adventurers who traveled through an ancient worlds with a technology known as a Stargate. It was a stable wormhole that allowed anyone who entered the ability to travel to a different planet and return home once their adventure was over. It would have been infeasible for everyone to live on Earth due to logistical constraints and our limited resources.

What this has to do with scaling

The year is 2017. We have developed blockchains that offer the promise of a limitless decentralized future. However many developers seemed to have missed the asterisk the marketing people neglect to mention on public chains. 10–12 tx a second, globally. This is currently a restraint imposed by physics and design mechanics. Uncle rates spin out of control if we push it too far. So for those that came for a bad approximation of math:

If your app needs to make more writes than that, or even near to that, YOU DO NOT NEED TO BE RUNNING ON THE PUBLIC CHAIN! Those transactions are for a global network, not your personal application. I do understand the common arguments: “it’s a free market let the market decide” and “fees will balance it out” or “everything needs a token and a contract” or even “but scaling and PoS and sharding and <whatever> will eventually come” These things are not true. They were marketing lies. Its easiest to accept this now. Will scaling happen at a realistic pace on the main chains, yes. Will it ever scale to the level where millions of dapps or twitter level data will be stored and transmitted on one chain, no. And it shouldn’t.

The public chains are a community resource; think national park, public lake, the beach. They exist for the everyone. Can you fish on a public lake, yes! Can you dragnet a lake for your business, no. This isn’t a blockchain thing, it is a corporate citizenship thing. It is a common problem in the world where businesses exploit public resources for capital gains. It is up to companies to be good corporate citizens on the block chain and minimize their foot print.

Contracts are Centralized

To get this out of the way. Tokens are centralized. A company owns the contract and creates the application and manages the marketing and product. If you were to really use a token (trading doesn’t count) it would cost you twice as much in gas as a normal transaction because you would need to send a tx to the token which will trigger another transaction to whatever dapp exists. They are a gimmick. Hundreds of thousands of real dollars have been lost on them because of a convoluted design in the original ERC. Several hundreds of million have been lost on other poorly written contracts. These thing are not the fault of the system, and there is no reason to ever hardfork to fix such naive problems. Humans will always write flawed code. Incidentally, if these contracts were run on side chains, the chain could be frozen and everyone made whole on the main chain.

Tying it all together

Companies want users to give them money to use their dapp. If they are a good business, they want everyone to use their app. They would love for others to build apps that can interact with their app and give it more value. They don’t want to deal with outside parties if the need to upgrade their application or be held criminally liable when they freeze everyone’s fund with a flawed code and are unable to fix the issue. Users are already familiar with companies that operate under this model. Services like Coinbase and Blockchain.info allow users to send in coins, interact within their ecosystem without fees, and the leave their world when you chose too. However, neither of them allow for auditing or transparency that a side chain could offer.

In SG-1 terms, every dapp wants to be its own planet, but connected to everyone else. The company can set transaction fees, exchange rates, launch multiple dapps for their blockchain platform and still have access to a public chain. They can also do cool experimental stuff like zksnarks, starks, or anything they feel brings value to their system with out jeopardizing the main public chain.

Enter the Stargate

What a blockchain Stargate looks like

Stargates can be designed in any language a company is comfortable with on their server. The software must be capable of interacting with an etherem based chain.

What you will need: ( at minimum)

• An account you control the private key
• A connection to the main chain
• Servers running your private chain
• A Stargate

What is a Stargate (finally)?

A Stargate is a server side application that listens for incoming transactions on one chain and sends a complimentary transaction on the other chain. A complimentary transaction should be defined as one in which sender and recipient are transposed. At genesis all the tokens in the private system are given to the Stargate account on the private chain. Every token entering or leaving the system will originate at this address.

Entering a world via Stargate:

On the main chain Bob sends 5 ETC to the Stargate account< a 2:1 sg>

The Stargate should:

• Identify the sender <Bobs account #>
• Identify the amount <5 etc>
• Create a transaction from the Stargate account on the private chain
• To the message sender <Bobs account number>
• in the proper amount<10 dappcoins>

Bob now has 10 coins on the private chain as he controls the keys on both side.

Dialing home with a Stargate

Bob is finished using a dapp so he sends 16 dapp coins to the Stargate address

The Stargate should:

• Identify the sender <Bobs account>
• Identify the amount <16 dappcoins>
• Create a transaction from the Stargate account on the public chain
• To the message sender <Bobs address>
• In the proper amount <8 etc>

Important notes:

The Stargate account is a regular account, not a contract.

If throughput needs to increase, more Stargates can always be added and seeded from the first.

Once inside your dapp ecosystem all of your brand dapps can interact however you want!

In your private chain you can add thing like zsl, or PoS, or PoA, pre-compiled contracts; and still have all the benefits of connecting to the public chain, but without the constraints!

You do not need tokens or even a smart contract to do this.

The main chain is now capable to scale at its own pace. Safely and securely and your users are not constrained by network congestion.

When Can One Do This?

Today! You do not need permission or approval. No need to wait on others to scale for you. Your dapp will scale better than those waiting for permission to grow. Your dapp will have the street cred of all the other crypto projects, but with the ability to actually be functional.

Stargate SG-1 and its characters are the property of Stargate (II) Productions, SCI FI Channel, Showtime/Viacom, MGM/UA, Double Secret Productions, and Gekko Productions.

This blog has been verified by Rise: R8583d2ae9be0ac8c1540f01530007a5b

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. — C.A.R Hoare

The Hash Box

This is probably one of the simplest bits of chain code I have written. But as with all things blockchain, I will lead in with an overly complicated story involving fictional characters. I think Bob and Alice get too much attention so I tend to use the lesser known characters in Cryptopia in my stories. They are all fictional so the names really do not matter.

Victor and the Contest

Victor has announced a contest to all of his friends. He will give 5 coins to whichever of his friend’s can comes up with the best song. Some of Victor’s other friends know they are not good song writers but would also like to donate to the contest. Since Victor does not want to hold all the money in his account(and his friends don’t really want him to hold it), Victor decides to build a plexiglass donation box with a lock and place it in the middle of town. Now everyone can see how much money has been donated to the contest and add money if they like. Since everyone is watching the money, the only thing Victor needs to keep safe is his key. Victor has also announced that he will give the key that opens the box to the winner of the contest and they will then get to claim all the money inside.

Building a Lock and a Box

On the blockchain (a digital “middle of town”) we have several tools to create locks. The cheapest secure lock we can use on ethereum chains is the SHA-256 algorithm. SHA-256 algorithm generates an almost-unique, fixed size 256-bit (32-byte) hash. Hash is a one way function — it cannot be decrypted back. It is the building block of most all blockchains in use today. It was included in the original ethereum code as a precompiled contract, meaning that the hash can be used with very little gas in any contract.

Since any data can produce an almost-unique SHA-256,it will work well for our purposes. We start by making a unique phrase that will be used as the key for our box. For the demonstration we will use the secret phrase: `Alice and Bob sitting in a tree.`

You can use any method you like to get the hash of the phrase, and as long as they use SHA-256 it will always return the same 32 bytes. We will set this hash as a public variable our contract so that anyone can read the hash. As the hash is a one-way function there is no danger of allowing others to view and verify it.

bytes32 public hashLock = e839dfa428e99c99630742d1086c99c51e5be27d702c47a786be6f17c8a3a16;

For a contract to receive and store ether we will need to set its fall back function to payable (making it a simple money box).

function () payable public{}

Now we have constructed both a box that anyone can send funds to and a lock/key for our box. Now we will need to add a way that anyone with the key can claim the contents inside.

function claim(string _WhatIsTheMagicKey) public {
require(sha256(_WhatIsTheMagicKey) == hashLock);
selfdestruct(msg.sender);
}

Let’s step through the `claim` function. When someone calls the claim function they will also supple a string that we are calling “_WhatIsTheMagicKey” The first step in the function will test if the SHA-256 hash of the string matches our HashLock. If it doesn’t the function will fail. If the two do match, It will send all of the funds in the box to the person who gave it the magic key. All or nothing (aka atomic). After that the contract self-destructs, cleaning itself up from the public state as it is not needed anymore.

In the Wild

Compiling the byte code can be done any number of ways. I use the built in compiler in Parity, but Remix or truffle will work just as well. I will use MyEtherWallet.com to deploy and interact with the contract.

Step 1: Deploy the contract

Step 2: Fund the contract

Step 3: Verify the Hash

Step 4: Unlock the Box

The Complete Contract

pragma solidity ^0.4.18;
contract HashLock {
    bytes32 public hashLock = 0x_007_YourHashGoesHere;
    function () payable public{}
    function claim(string _WhatIsTheMagicKey) public {
        require(sha256(_WhatIsTheMagicKey) == hashLock);
        selfdestruct(msg.sender);
   }
}

Conclusion

The hash box can be used for many things. Bug bounties, contests, simple escrow, you name it. I set the gas price to 10 Gwei so my entire series of tests cost around $.002 USD. This is a simplified version of the hash/time lock contract used in atomic swaps and will be a key building block in a public mixing service coming up.

Part 2: turning a box into a xob….. coming soon