There is a new startup in the Ethereum Classic space that has caused a bit of a stir with their initial actions and I would like to take a few minutes to comment on them. For brevity, there is no distinction made between etclabs, the “startup incubator” and DFG, the desperate speculator group. Some may remember them as they made presentations at the ETC summit and they have held themselves out to be a new development team in the space and hopefully they can recover from their recent missteps and join the other dev teams working in the space. Since they are struggling and need some air time, I am writing this open letter to ease the on boarding process.
Not like this
How Git Hub Works
For clarity sake, github is the system many open source projects use for coordination and version control. It is one of about 5 systems in the CI/CD pipeline that are used to ensure distribution ETC related software. Individual repositories(repos) contain projects, and they are consolidated into organizations (orgs) for easy of search and moderation. There are two roles that are part of a github org, member and owner. “Owners” have the ability to add members, add/del new repos, and change members status (even removing other admins status), and more importantly add CI/CDapps and web integrations, You broke all of those because you are incompetent, please ask if you don’t know what you are doing. There are infact, and have always been, several ”ETC” orgs. IOHK, Parity Tech, BCRD, ETCDEV, etc. In the past, they work on code in their parent org and then merge it with the main branch in the ethereum project org for easy of coordination. Owners do not “own” open source orgs(google: foss), members do. Members are allowed to submit and merge code. Should the new dev group, ETCLABS, have been made members, absolutely! In fact anyone who wants to contribute can and should be made a member. After they foolishly removed all admins from the ethereumproject repo and lost control of the krykoder account, I added them as members to the back up organization ethereumclassic. I have transferred all of the projects I had created to the new repo and the chain moves on. Currently there are 4 “owners, and I will direct you to the volunteer page to see the new requirements that no admin can remove other admins without consent of all to prevent accidents like what had happened to the last org. We are more than happy to add more “owners” if the need arises. But you will need to actually produce work and be active in the community, money doesn’t matter.
ECIP process ETCLABS has express concerns about not having a voice in the process of improving ETC. The first resource they should use is https://ethereumclassic.org . It will answer many of your noob question regarding testnets, wallets, dapps, etc. If your only concern is about price, I canât help you there other than saying ethereum systems work better when the price is closer to zero than 1 million, but as a speculator group you should have looked into that before losing everyone’s money. For anything else that can improve the ecosystem or network, you need to follow the Ethereum Classic improvement proposal process. This is the common way to make suggestions, you don’t need to strong arm a development team or even ask permission. The repo is located at github.com/ethereumclassic/ECIPs now that the ethereumproject repo has been deprecated. You may be interested to know that another development group with actual chops has proposed a universal set of status codes, I had proposed op code compatibility changes(which should be coming sometime after the Constantinople fork opcodes are tested in January), and several other exciting things that maybe etclabs can even try to help with.
In conclusion
Welcome to Ethereum Classic ETCLABS! I look forward to the day you actually produce anything other than bizarre press releases. Also, please try to refrain from using my name in your revisionist history unless it accurately reflects my contributions to your work. Aside from once conference call with the other development teams, in which you profusely apologized for screwing up the git org, I have never been in contact with you. Feel free to ping me on literally any social media channel as dontpanicburns or email me if you need anything.
Modern blockchain technology relies on different principals than previous generations of blockchains, known as UTXO or generation 1.0, and allows for more robust transaction execution. An introductory stateful blockchain can be expressed as a game of correspondence chess.
The rules of chess are understood by all participants in the network and, as such, it is understood that a knight has a certain series of functions, or moves, it is able to perform. The same holds true for the other pieces of the game.
Genesis state
The genesis state of a traditional the game is presented in figure A. Both participants have a series of pieces that they are able to use and have agreed on the current positions of each. This is conceptually similar to smart contracts on a blockchain. Each contract has a predefined set of functions that are controlled by rules just as each piece as a predefined set of moves it is allowed to make in game play.
Consensus
In the correspondence chessboard network our consensus mechanism is set as such: each member must make 1 legal move per block. Once the player decides on the move, it must be submitted to a judge. Unlike modern blockchains, the chess game also requires each participant make their move in proper order. The dark pieces are forbidden from sending a transaction until the light pieces have made their commitment. When the light side player submits their move to the judge, it is visible to everyone and unable to be changed. Once both sides have made their commitment to a move, the block is captured as a list of moves (state changes) in PGN format and numbered from the genesis state.
The blockchain and the state
An example of a possible valid block number 1 could be: 1 d4 ♞f6. The
“blocks” are just a list of the moves that were made, not the actual pieces. This can be translated as the light side moving the pawn from d2 to d4 and the dark side moving their knight from g8 to f6. Both are valid moves and arrived in the correct order, so per our consensus rules this is a valid block. Each player will update their board with the new ‘state’. Players are only concerned with the current state, which contracts they can interact with, and what move they want to make next.
Syncing and Validating
As the game progresses, it is possible for any outside participant to validate the current state by reading through a the PGN list of moves from genesis and recreating the game. In the blockchain space this is known as syncing a node. If one of the players needs to take a break or knocks over their board, they are able to sync their board to the current state by reading the move list. A faster way of syncing would be to take a snapshot of the current state and send it to the validator along with the PGN. They would then have the current state and can validate it as needed. This allows for seemingly complex chess games to be replayed and studied by a broad audience.
State size and the evm
In a stateful blockchain system such as Ethereum, all of the rules from above still apply. Each node keeps a copy of the blockchain so they are able to validate their current copy of the state and the state began at a commonly agreed upon genesis block. By viewing the state, a participant is able to see contracts on the system in the same way they would see all the chess pieces at any state in the chess game. Similar to each chess piece, each smart contract has a series of rules and permissions associated with it. that govern its behavior. In contrast to the chess game, participants in the ethereum network are able to add valid contracts at any time in the form of a transaction. They will send the transaction to a node responsible for creating valid blocks. Once a series of transactions have been validated, the block of transactions is sent to all the participants who then update their local state. Participants only care about the current state, which contracts they can interact with, and which transaction they want to make next. As the state is shared between all participants, it is important to minimize the amount of data stored on leaf nodes of the states Merkle tree
image from ‘Merkling in Ethereum’
In an ethereum system, all accounts follow the same formatting scheme and are mapped by their unique account address. Both user accounts and contract accounts are stored in the same manner. Each account has:
The nonce, a counter used to make sure each transaction can only be processed once
The account’s current ether balance
The account’s contract code, if present
The account’s storage (empty by default)
Each node stores a list of all accounts that have ever made a transaction on the system and maintains the Merkel root of all accounts. When a transition arrives in a block, the new state root is computed and validated against the blocks state root.
The Zcash value proposition is in private transactions, however, private transactions are not the default and many users simply do not know how to initially create shielded (private) transactions, aka a “t” => “z”. In simple terms, it is important to have a large pool of shielded transactions provides for a larger anonymity set for private transactions; it is harder to pick out any one zebra in a large zeal than it is to point out a single animal in a small cluster. This process, and having more people familiar with it, provides greater value to my work on cross chain atomic swaps (x-cats in zcash speak) so I have attempted to unravel the apparent mystery below. No math, dark magic, animal sacrifice required.
Side note: If you would like to contribute to the greatest good, while exerting minimum effort for the zcash ecosystem, hold you coins in a “z” address. this benefits everyone using zk transactions and increases the size of the anonymity set. Currently, as shown below, this is an uncommon practice.
The general process for shielding ZEC is as follows:
Generate both a “t” address and “z” address
The “t” address works the same as a bitcoin address. When you send from your transparent address the change from the transaction will be sent to a new t address you control and all the transactions will be visible on block explorers. “Z” addresses are the private ones and you will only be able to see the balance in the wallet. When sending to and from a Z address, only the exact amount (minus fees) is sent, the change remains with the same “z” address. No one observing the transaction will see any information about the “z” address, except during shielding and deshielding.
2) Fund the “t” address
Funding your “t” address means sending ZEC to it. Zcash can be traded for or purchased many places. Gemini allows US customers to purchase ZEC with US Dollars.
3) Send from your “t” => “z” using a zcash wallet such as zcashd or winzec
It is actually as easy as that sounds. Sending from “t” to “z” or “z” to “z” or “z” to “t” is all the same procedure. This step is overlooked in the zcash documentation because it is so trivial. Maybe they will add it in future versions to avoid confusion. https://github.com/zcash/zcash/wiki/1.0-User-Guide
Notes
“t” addresses send change to new accounts, “z” notes do not
do not send from “z” => same “t” or the change account, always use a ‘clean’ “t” address when deshielding
avoid sending the same amount into and out of shielding transactions. While 10 zec in and out is less traceable than 2.3123 zec, 10 zec in and a random amount of zec out is better
Download the “unofficial” windows version of zcash. It can be found at http://winzec.com/
1. Create addresses
click the new T (transparent) address button
click the new Z (private) address button
2. Fund
Fund your “t” address
3. Send
winzec
On the send cash tab, select your funded t address. enter your z address in the destination address and the amount to shield.
Click send and watch the progress bar to see when it completes
That’s it!
Note: When you are sending, there are two fee boxes. The first is the network fee, you must pay this to have your transaction included in a block. The second is the wallet dev fee, this is an optional donation to ralfstx to support the windows and mac wallet development. If you have used both methods, you will quickly realize the importance of gui and its continued funding. Open source development is often a thankless process, so money is always nice way of saying thank you.
Let’s preface this article with a bit of hand waving. Please assume that we live in a world 5 minutes into the future where we have figured out AR implants or non-ridiculous glasses. However, for now your mobile exo-brain(phone) will work.
I will begin by saying I have felt robbed for some time now. Something is missing. I was promised the future would be a late-stage capitalism state where I would be inundated with interactive 3d advertisements in a gloomy Phillip K. Dick urban sprawl. Granted we are close. I build and trade imaginary internet coins, work for a multinational tech conglomerate, carry a super computer in my pocket, and have a handful of nonhumans living in my house. But I know we can do better. Also <*handwaving intensifies*> in a more decentralized way! Free market persistent advertisements should be everywhere now. Since no one seems interested in making this a reality, I guess I will have to step my game up. Be the change.
On of the most common pitfalls of modern AR is the lack of continuity with actual reality and even itself. I believe this disconnect can be remedied with modern public blockchains. In order for the system to be robust enough for wide spread usage, it will need distributed file storage for rapid access of the advertisements, a public market for advertising space, and a simple recognizable target for the advertisement(to project on, obviously YOU are the real target). And it also goes without saying this will all need to be open source. With these requirements in mind: lets do this!
Burns Capital: Research and Development
For this proof of concept we will be using a the Burns Capital . The success criteria will be if you, the reader, are able to see this logo on demand anywhere in the world. I am using a simple image for demo, however it is just as easy to make 3d objects and any other aframe.io objects using the same method. That will hopefully be covered in another article. Also, This is living code so it will be updated likely by the time you are reading this. The repo link is at the bottom, its open source, help yourself to the latest code base.
Before we get too deep into the coding aspect of the system lets briefly look at the network design. 1) A user is served a lightweight web application from ipfs, 2)the webpage uses a public api to access a 3) contract on the ETC network to get information about targets and 4) the advertisements are then retrieved from ipfs and 5) displayed at the target. I refer to this as zero weight architecture.
Dive deep!
File storage:
This one is the easiest of the four requirements. If you are unfamiliar with the interplanetary file system (IPFS), stop everything you are working on, learn about it, and start using it now. When a file is added to the ipfs, it is given a unique identifier. This identifier is used to distribute the file to other ipfs nodes and recall it as needed. Super useful in our case.
The BC logo is now available EVERYWHERE!!!!!! Not super impressive, the internet has existed for some time now but we can now access our unique image using an ipfs API point on our machine or any other machine attached to the ipfs system using its id. The file is also publicly available at the ipfs api point is located at: https://ipfs.io/ipfs/QmRYrsq4uHk3AuVapdyoPtbF4zuzw7dbkc4r8HBKssB3De
Distributed access
Constantly passing around QmRYrsq…. is painful and scales poorly. Being a blockchain architect by trade, this is obviously the job for my baby: Ethereum Classic! We will need a contract which we are able to write to once, and read many times. It would also be nice if no one could over write my logo with out my permission. Other nice to have features include: public rating system like movies and games have, the ability to resell my ad space, and a one to one mapping. To do this we will create a structure and an enum.
For simplicity in this demo, we will only be using uint8. This gives us 255 unique seats to map advertisements to which should be plenty to demonstrate the concept.
mapping (uint8 => arTarget) public targets;
A bit on targets
We will be using a 3×3 matrix format without error detection or correction, allowing up to 64 different markers to be identified. They 3×3 targets can be downloaded from this link for your convenience. Yes we are only using 64 of the 255 available seats. In a real future world production environment we can easily scale this up to many many more seats and use a slightly larger grid. The idea is to avoid overly complex structures like qr codes and keep it human readable and if need be drawable.
Reading data from a target
We will need a simple getter to allow users to access the stored information. The two most important pieces of information we will need are the image identifier and the content rating. Some sort of nanny monitoring software should be able to read the content rating and block sensitive viewers from seeing age inappropriate items if desired(out of scope).
function getLogo(uint8 _scan) public view returns(string ipfs, ratings rating){ ipfs = targets[_scan].logo;
rating = targets[_scan].rating;
return (ipfs, rating);}
Buying(and selling) a Seat
This is where things get a little tricky. We need a way for owners to update their seats, new users to buy seats, and both to buy and sell.
function updateLogo(uint8 _arID, string _ipfs) payable public returns(bool success){}
We will take an ID and a string with the unique identifier. This function is payable so we can allow users to buy seats. If everything goes well, we will return a successful result.
The easiest case, a seat is not owned and someone wants to occupy it; we let them. That would look like this:
To save space we will combine the actions that an owner can do and what a stranger can do to an unowned asset. Just pass everything you need to claim a seat
As I have no desire to host a distributed crush film repository or any other hyper-objectionable content we will also add a rating review board and give them the ability to remove content. They are free to make their own system if they like, but I won’t be complicit in supporting it. So to accomplish this we will map the account address of our police union to a boolean variable(true for police, false for non police) and create a modifier we can add to some function that only the content police should be able to do. And in the spirit of transparency, we will publish an event whenever the pigs take something down. It will report the action(“removed item”), which public servant removed the content, and a comment string if we want to capture a reason.
To give our thought police something to do we will give them this function:
function clearSeat(uint8 _seat, string _comment) public onlyContentPolice returns(bool success){ targets[_seat].owned = false;
targets[_seat].logo = “”;
emit squeal(“removed”, msg.sender, _comment);
return true;
}
Now we have a short public storage database contract for our advertisements!
Compile and deploy using your favorite blockchain interface and were ready to go!
The AR part!
Welcome to the world of tomorrow! Aframe.io and AR.js will be doing all the heavy lifting for us. These opensource projects are working to bring vr/ar to the masses by building out the webVR frame work. For a quick intro on making an AR project with 10 lines of code check out: http://aframe.io/blog/ar.js
<disclaimer: I’m not a frontend developer>
We will be adding web3.js to the ar demo so we can interact with our blockchain. To do that we need to add the following to the html:
var web3 = new Web3(new Web3.providers.HttpProvider(uri));
console.log(web3);
Of course; changing the uri to your preferred api point. For the demo page I will be using the etc commonwealth public api point. Add the contract logic :
console.log(“ o Setting up contract”)
var contractAddress = “0x9868a675D36E2554F559771539F00Ed188A33e69”; var abiArray =[{"constant":false,"inputs":[{"name":"_seat","type":"uint8"},{"name":"_comment","type":"string"}],"name":"clearSeat","outputs":[{"name":"success","type":"bool"}],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"name":"_arID","type":"uint8"},{"name":"_ipfs","type":"string"},{"name":"_forSale","type":"bool"},{"name":"_price","type":"uint256"},{"name":"_rating","type":"uint8"}],"name":"updateLogo","outputs":[{"name":"success","type":"bool"}],"payable":true,"stateMutability":"payable","type":"function"},{"constant":true,"inputs":[{"name":"_scan","type":"uint8"}],"name":"getLogo","outputs":[{"name":"ipfs","type":"string"},{"name":"rating","type":"uint8"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[{"name":"","type":"uint8"}],"name":"targets","outputs":[{"name":"logo","type":"string"},{"name":"owned","type":"bool"},{"name":"owner","type":"address"},{"name":"forSale","type":"bool"},{"name":"price","type":"uint256"},{"name":"rating","type":"uint8"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[{"name":"","type":"address"}],"name":"contentPolice","outputs":[{"name":"","type":"bool"}],"payable":false,"stateMutability":"view","type":"function"},{"inputs":[],"payable":false,"stateMutability":"nonpayable","type":"constructor"},{"anonymous":false,"inputs":[{"indexed":false,"name":"action","type":"string"},{"indexed":false,"name":"officer","type":"address"},{"indexed":false,"name":"comment","type":"string"}],"name":"squeal","type":"event"}]; var arContract = web3.eth.contract(abiArray).at(contractAddress);
When the viewer loads we want to call the “getLogo” function to get our advertisements and assign them to their respective targets. If no one is the owner of an object, we will show a “for sale sign”
console.log(“ o Assigning assets”); for( i = 0; i < 6; i++){
console.log(“ response from contract”+arContract.getLogo(i)[0]);
This is a very simplistic system for demonstration purposes. Don’t let its simplicity fool you though, this is a live system on the public block chain. The contract can be found and interacted with at: 0x9868a675D36E2554F559771539F00Ed188A33e69 using the abi in the github repo.
For brevity in this article I use the term “Ethereum”, however this applies to all systems based on the “preDao Ethereum Prime” that spawned ETH, ETC, EXP, ELLA, and many other versions.
Process this before proceeding:
Ethereum was never ASIC proof and it is no longer ASIC resistant.
Intro
Asics for ethhash are here. They are currently and have likely been here for some time and are mining on the public chains. They are much cheaper and energy efficient than current GPU mining rigs and are only available from one source. Their construction is not opensource and no one outside of their manufacturing chain knows how they work, how they process data, or anything about them outside of what has been publicly announced by Bitmain.
Understanding the incentive model for ASIC production requires no knowledge of cryptographic hashing or wonky block chain minutia. Mining is a for profit business. Their profit is a product of their revenue minus variable costs and fixed costs. If they can lower their costs they profit more. Asics are more efficient per mh/s on electric, cheaper, and smaller, offer a clear advantage over current GPU mining rigs.
ASIC resistance is not ASIC proof
How did we get here? Why was Ethereum designed to be ASIC resistant? How was Ethereum ASIC resistant for so long?
A long time ago in a blockchain long forgotten, Ethereum was meant to use Proof of Work until the magical system of PoS was implemented back in 2016. Design and technical debt was added to the system in the form of a difficulty bomb and an ever-increasing DAG to ensure this utopian dream would happen. Both were “temporary” and intended to deter large capital investment in Ethereum mining. Both were poorly thought out for long term sustainment. The difficulty bomb has been removed by both main chains of Ethereum now as it was unproductive and more harmful than necessary. Good riddance. The DAG is something not often discussed outside of mining. The DAG is the property of the ethHash mining function that creates a need for an ever-increasing amount of memory. Memory, being very expensive to add to an ASIC, has been the limiting factor thus far in resistance. The DAG began at 1GB and is currently ~ 2.4 depending on which chain you are mining on. If you have purchased any GPU in the last 18 months you will have noticed a steep price increase at the 4gb size as these are the only cards that are now capable of handling the DAG. Any GPU card or ASIC with less than 3GB( good until April 2019) is unable to meet the current memory requirements to mine. This limits mining to high end cards and, now, ASICS. This constant DAG growth will eventually lead to a broader discussion about bus sizes/speed and memory constraints on consumer grade GPUS, but that is for another post.
How to effectively combat an ASICS without knowing anything about their design.
Step 1
Reset the DAG to its initial 1gb state.
Step 2
There is no step 2
Resetting the DAG to its initial state and letting it grow retains all the proprieties of ASIC resistance that have always been afforded by making ASICS non competitive on the metric of accessibility. This action would allow nearly every GPU on the planet the ability to mine, while still ensuring it is non trivial to construct ASICS. The hobbyist miners will be given a method of combating centralized ASIC miners thus allowing the community to help themselves by dusting off their old cards and rocking out.
The alternative of doing nothing and really hoping PoS comes or moving goal posts ever 6 months with new algorithms are both incredibly risky and “forky” solutions. Resetting the dag is trivial code wise and great for everyone. Unless you just spent a ton of money developing ASICs.
Inactivity strikes us as intelligent behavior. Neither we nor most business managers would dream of feverishly trading highly profitable subsidiaries because a small move in the Federal Reserve’s discount rate was predicted or because some Wall Street pundit had reversed his views on the market. Why, then, should we behave differently with our minority positions in wonderful businesses? — Warren Buffet
In part 1 of the series we learned about conditionally locking contracts that allow for two parties to transact value on an ethereum chain using a secret hashed password funds could be kept in public view and then retrieved at a future time. In this article, we will allow a user to send coins to a contract for safe keeping until some point in the future. In crypto trading terms this is know as “Hodling” and is an optimal strategy in investing in general( see: Warren Buffet)
The History of Hodl
In 2013, a user named GameKyuubiposted a now infamous, admittedly drunken, post on his poor luck as a trader.
GameKyuubi understood the importance of holding assets long term as a value investor, however, they lacked the strength of will to do so with the ease of trading options that were available. It is by this example that we will work on a chaincode that will allow the block chain to do the hard work “Hodling” for us.
Send funds, get later. All of the following contracts will be made available for use on SaintHodl.com for ease of access and are also available as an open source resource on github. You can use your Jaxx.io,MEW, or any Ethereum Classic wallet to interact with them, for free!
The Most Important Part
A time locked contract cannot be opened early. You cannot negotiate with the blockchain, your locked funds are safely tucked away until the predetermined amount of blocks have passed. No backsies.
So in the time locked contract (TLC) this variable is made public and is listed first. Anyone viewing the contract should easily be able to view this number and know what they are getting into ahead of time. In sainthodl’s contract it is written as:
uint public freezeBlocks = 20;
This sets the contract freeze time up for 20 blocks, which is ~280 seconds or 4.67 minutes. Not a long time, but enough for testing. (There is a 2 million block option on site if you are looking for something more 😉 )
Freeze blocks viewed on
Lockers
In part one, hash boxes were publicly view-able. The same will be true with our TLC contracts. Each ‘box’ will consist of 3 details: the owner, how long to hold coins, and how many coins are being held.
Every address will now be mapped to a unique locker.
Sending funds to a Locker
Whenever anyone sends coins to our TLC contract we want it to add funds to their locker and set the freeze time to some block in the future. To do this we will be using the fall back function in the solidity contract:
function() payable public { locker storage l = lockers[msg.sender]; l.freedom = block.number + freezeBlocks; l.bal = l.bal + msg.value; }
The locker will be identified by the user sending funds( locker “l” is the locker of the message sender). We then use the latest block.number and add the predetermined number of freeze blocks to get our “freedom block”. The lockers balance will be calculated from its current balance (0 normally) and the value that was sent with the message. If you use the abi from the github with MyEtherWallet.com you will now be able to see everything in the locker (Balance will be in Wei)
Using Mew Contract interface
The Second Most Important Part: Withdrawing
Finally, the urge to panic sell has passed, and you can now safely be trusted to get your funds back. Unlike the hashlocked contract where anyone with the preimage could claim the funds, only the owner of a locker is able to withdraw their funds from the TLC. A word of caution; when allowing strangers to withdraw from a contract it is important to avoid opening up to recursive calls. The Dao contract failed because of this design flaw. This would work by someone calling the withdraw function from a contract that had its fallback function set to also call the withdraw function. To avoid this we will set the lockers balance to zero before we send any funds; this way if a contract calls back it would only be able to withdraw zero.
function withdraw() public { locker storage l = lockers[msg.sender]; require (block.number > l.freedom && l.bal > 0); // avoid recursive call uint value = l.bal; l.bal = 0; msg.sender.transfer(value); }
Similar to the first function, locker “l” is the locker of the message sender. We then require that both the current block number be greater than the lockers freedom block and that the lockers balance be greater than zero. If either of these conditions are not met, the function will ‘fail’ i.e. not do anything. If both conditions are met; the lockers balance is saved as ‘value’, the original balance is set to zero, and then value is sent to the locker owner.
Withdraw function on Mew
Events
If you read through the contract you will notice two “events” that show up:
These events are displayed in wallets that watch for events and can be used to trigger things like posting to twitter.
Contract as viewed in Parity
Conclusion
With this simple contract anyone is able to commit and retrieve coins on the chain for as short or as long as they like. Part 3 will combine the functions of part 1 & 2 to create a hash-time locked contract to do some really cool things!
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:
For reference
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
Paste the bytecode in the deploy contract section on MEW. This will create a new contract.
Step 2: Fund the contract
At this point the lock box is set up. Add as much money as you like, the only way to get the coins out is with key.
Step 3: Verify the Hash
Since hashLock is constant it is free to view.
Step 4: Unlock the Box
Use the ‘Claim’ function can now be called by anyone with the key to get the funds out of the account
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.
In this article, we will create a series of contracts which will allow two people to exchange coins across chains in a trustless atomic manner. An atomic transaction is an indivisible and irreducible series of transactions such that either all occur, or nothing occurs. The contract used is complimentary to BIP-199 so it can be used to transact from ethereum based systems to ethereum based systems or Bitcoin based system(assuming HTLC is allowed).
The difficult problem with cross chain swaps is the off chain coordination required to have the two parties meet and agree on conditions. It is outside the scope of this article, but any communication channel can be used really; email, slack, twitter, reddit, etc….
The background work that makes all of this possible is from BIP-199:
“A Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the “seller”) to spend funds by disclosing the preimage of a hash. It also permits a second party (the “buyer”) to spend the funds after a timeout is reached, in a refund situation.”
Victor (the “buyer”) and Peggy (the “seller”) exchange public keys and mutually agree upon a timeout threshold.
Peggy provides a hash digest. Both parties can now — construct the script and P2SH address for the HTLC. — Victor sends funds to the P2SH address or contract. Either: Peggy spends the funds, and in doing so, reveals the preimage to Victor in the transaction; OR Victor recovers the funds after the timeout threshold.
On the Ether chains:
Peggy will be played by account: 0x9552ae966A8cA4E0e2a182a2D9378506eB057580
Victor will be played by account: 0x00D29a21429ad90230aCe2B9a1b25fa35bb288B8
The entire transaction explained:
Peggy will:
be locking up funds on etc chain (contract A)
that will be sent to Victor
when the message that hashes to digest is received
Victor will:
be locking up funds on eth chain (contract B)
that will be sent to Peggy
when the message that hashes to digest is received
Our preimage(“this is a test”) hashes to 2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c
1 hour timeout
1:50 (1 eth = 50 etc) exchange rate
Everything for the test was deployed to the mainnets of both chains and is there available for review. I have included links where practical. All contracts were deployed with MyEtherWallet using byte code generated from the contract located here. To use this contract as is with out spinning up a node: copy and paste it into remix, fill in the variables for your transaction (hash, time, destination) and copy the byte code to MyEtherWallet to sign and deploy. You will need to create new contracts for your swap .To interact with the contract you can use this abi with the contract address in MyEtherWallet.
Step 3: claim cross chain funds Peggy claims her funds from contract B, reveling the secret Victor read data from contract B , get the key, and claims funds on contract A
That’s it! A little anti-climatic that it only takes 3 steps I guess, but everything on a block chain doesn’t need to be hard. If Peggy never claims her ether, Victor can never claim his. If Peggy does claim her’s she reveals the secret and Victor is free to claim his. The timeout exists so Peggy and Victor can claim their funds if something goes wrong.
