A decentralized and anonymous new crypto-platform.
The ethereum platform is, shortly, a distributed computing network that creates and manages a
indisputable ledger of transactions. Additionally it provides some functionality that allows
programs to be compiled and run on the network, by the computers hosting the network. Making
transactions requires ether, the native currency on the platform. Like a car, the ethereum
platform runs on gas and ether is the fuel.
Ethereum uses public-key
cryptography (it is a crypto-coin after all) that works very
similarly to message encryption. In public key crypto a user shares their public key and others use it to
encrypt the message. Now that it has been encrypted with the public key, the only way to get
anything meaningful out of the encrypted message is to decrypt it with the private key. The
ethereum platform works in a similar manner. When an account is generated, an algorithm
spits out a random public key and its corresponding private key. Only the owner of the
private key can make any transactions on the behalf of the account. This includes sending
ether, which means that we have uncovered a glaring vulnerability.
The Current Security Landscape
A central and catastrophic point of failure.
In its current form, ethereum wallets have a single point of failure. Anyone with access to a
wallet's private key has full control over all the funds in that account meaning any
security breach is catastrophic and irreversible (ie. any security breach is a complete security breach - the idea
of a partial breach is foreign to a system where a single key means control). There are multiple methods that we can use
to mitigate these problems, all of which share the same shortcoming. One of
the most common alternatives is splitting your funds into hot-and-cold wallets. Acting
similarly to a checking-and-savings account, a cold wallet stores the majority of your
assets, letting you manage them from an offline or air-gapped wallet to ensure isolation
from malicious software. The primary ideology here is that if your "hot" wallet, or checking
account were compromised, your "cold" wallet, or savings account would remain safe.
This method still has a central point of failure. If a key is compromised (or lost)
funds are irreversibly gone. If you save the key in only one place, you risk losing the key
(ex. from a fire); the only way to counter this is to save the key in multiple places which
opens up another vulnerability: theft, physical or electronic.
To patch this vulnerability, we need to devise a solution that guarantees that a security failure
is not a total failure, implementing a series of failsafes that ensure that the account only holds
value for the account owner, and that any potential attacker would derive no benefit from stealing the private key.
Luckily, as mentioned briefly in the introduction - and because ethereum is a computing platform
rather than just another block chain crypto-currency - we can create a solution that
completely absolves the risk of losing a key. This revolves around a class-like
structure on the ethereum block chain: the smart contract. The public and immutable ledger
that ethereum is built on ensures that any code uploaded to it (and irreversibly fused with it)
operates exactly as defined at inception, completely resistent to modification.
This contract then exists on the decentralized network, ready to be engaged by anyone,
and benefited from by everyone.
The Lyon Banking Contract
A safe banking method to store the ethereum of multiple users.
Smart contracts have all the rights of a regular account, but are controlled by code. This
means that they may hold and spend ether, just like a regular account. Additionally, a
standard known as ERC-20 has
defined "tokens" or "coins" that exist as sub-currency on the platformm. These can
be created by any contract, and the contract needs only support a small set of functions to
make it ERC-20 compliant. Using a combination of the contracts' account-like properties,
some unique functionality, and our own token, we can safely trade ether with the contract, and
in return receive tokens that have no value to malicious parties but can be traded back in
for the original deposit.
The system relies on three separate layers, outlined below.
Managers
Two trusted addresses are assigned the role of managing the withdrawals. Any
attempts to cash in tokens will then need to be approved manually.
The third address is safely stored such that both managers must be present to
access it. This means that a compromised manager can be replaced with a new,
(secure) address with zero asset loss.
Transactions
A withdrawal request is made, and upon confirmation the ether is deposited back
into the owner's account and the equivalent tokens retracted. Any transaction
is cancellable.
Users
Funds are deposited into the bank in return for tokens. These cannot be
cashed in or traded without approval from the managers, meaning the tokens
are theft resistant.
The tokens mean that if a user were to lose their address, their cold funds are
safe inside the bank and the tokens can be transferred easily to a new address.
Problems Solved
Communication between the decentralized and the centralized.
Requiring manual approval from a trusted party resolves a few issues but also presents new ones.
Here is how they are solved.
When a User's Account is Compromised
When a user experiences an account breach, all the funds in their account are locked unless consent is given
by the managers. This means that the account holder can speak with the bank managers and
initiate a token transaction to a secure wallet, and have the correct transaction - to the new, safe, address -
confirmed by the managers.
transfer(address _to, uint256 _value)
The compromised account initiates a transfer of their tokens to a new account and informs the admins of the
situation.
approveTransaction(uint transactionId)
The managers, knowing which account the funds should be transferred into, approve the transfer. When enough
managers register their approval, the transfer executes and the tokens change owner.
When a Manager's Account is Compromised
Managers are essentially users with additional priveleges, meaning the process is similar for both. First,
transfer assets to the new wallet and then initiate a manager change to then be confirmed by the remaining managers.
createManagementVote(address from, address to)
A management vote is created to be approved by the other manager accounts. In our specific architecture,
the uncompromised account, along with the owner on the compromised one retrieve the third key and use that
third key as the second vote to change manager.
approveManagementVote(uint changeManagerId)
Similar to the transaction vote, approveManagementVote() registers a manager's approval for the
specified action which, upon reaching the required number of votes, executes and transfers ownership.
Events
Communication between the decentralized and the centralized.
The blockchain is a history of blocks which are fundamentally themselves just lists of transactions. Each
transaction has an attached receipt which contains zero or more log entries. Log entries
represent the result of events having fired from a smart contract. Events are dispatched
using signals the smart contracts can fire. Programs off-chain can then listen for these events to stay
informed about various happenings on-chain.
Account Related
Managers
CreateManagerChange
This event is called by the function that changes managers in the event of one of the
keys getting lost or compromised, an initiates the manager change process.
ApproveManagerChange
This event is called when a manager votes on the manager change.
CompleteManagerChange
This event is called when the managerchange motion receives enough votes and is approved.
Members
MemberAdded
This event is called when a new account is added to the list of members.
MemberRemoved
This event is called when an account is removed from the list of members.
Transaction Related
CreateTransaction
This event is called when a withdrawal from the bank is requested.
ApproveTransaction
This event is called when a withdrawal from the bank is confirmed by a manager.
CompleteTransaction
This event is called when a withdrawal from the bank is executed.
Deposit
This event is called when money is successfully deposited into the bank.
Self Distruct
The bank, as a safety measure, may shut down operation immediately refunding all users
of their deposits and blocking all future transfers rendering it completely inoperable.
This self distruct - as with all other actions - must be approved by managers first.
SelfDistructVote
SelfDistructComplete
Implementation
The software behind the smart contract.
With our intentions clearly presented, we are ready to implement it. With an ERC-20 token
as the basis, we will start by implementing the methods defined in the standard. These are:
// core functionality
function totalSupply() returns (uint256 totalSupply); // the total number of tokens in circulation
function balanceOf(address owner) returns (uint256 balance); // the balance of a particular address
function transfer(address to, uint256 value) returns (bool success); // transfer a users tokens to another address
// allow other users to take money out on your behalf
function transferFrom(address from, address to, uint256 value) returns (bool success); // transfer from one address to another
function approve(address spender, uint256 value) returns (bool success); // approve an address to withdraw a certain amount
function allowance(address owner, address spender) returns (uint256 remaining); // check how much you can withdraw from another account
