New standards in blockchain software
The world of blockchain today very much resembles the days where everyone would be building their own network on the internet without common standards, hence without guarantee of intercommunication capabilities.
Widely accepted standards are hard to be accepted as they seem not worth the effort, and the most difficult part is coordinating competing companies.
While this is very understandable as the market is very new, totally unregulated and everyone is looking to get the first-mover advantage, this makes communication between decentralized applications not so easy.
One further point is that developing decentralized applications on Ethereum requires thinking in terms of components and adopting a decentralized point of view, which is not so immediate for developers who are accustomed to server-based approaches.
Ethereum itself was born to collate between the different groups of blockchain developers trying to fix different problems without benefiting an underground generalized flexible architecture.
All of us who have been in crypto long enough have testified the advent of hundreds of coins born as a Bitcoin fork, for the sake of having “your own coin” or to (either marginally or substantially) improve the Bitcoin protocol. With that came hundreds of different blockchains which were doing more or less the same thing.
With Ethereum we have seen how one does not need to create his own blockchain, and can instead leverage on a public blockchain to create his own tokens. This is for sure a quantum leap (aka one huge step forward) towards a global financial markets made of tokens: after the token economy, we finally have the token-financial-world.
The beauty of inter-exchangeable, globally-transferable, no-national-barrier digital tokens has opened the door of hard-to-invest-in companies to virtually anyone, democratizing access and setting a standard for crowdsales (even though thy are all different from one another in some respects and exceptional analytical skills are needed to be able to properly assess the various projects).
With the maturing of the technology, we believe common standards will emerge. This will be for sure in the field of crowdsales, as they are getting a lot of attention lately. But it will also happen in the field of decentralized applications development.
Setting the standards will allow projects to focus on what they can do best, and integrate external services smoothly. We believe this is the way going forward: decentralized applications intercommunication. Notable projects looking to set a standard for interchain communications (Cosmos and Polkadot just to name two) are getting a lot of attention.
In our case, we would like to see a common standard for decentralized exchanges, since our Dragos are decentralized pool of tokens which are used for trading on decentralized exchanges. Even though our pools can live even without a common standard for exchanges, we believe it will make every developer’s life much easier having some strong fundamental base to build on top of.
The below is a generalized abstracted interface for decentralized exchanges we’ve been working on. It is based on the 0X protocol and can be used as a general interface for both decentralized exchanges and hybrid centralized exchanges. We are still working on it, but we have managed to fit two very different types of exchanges in it: hybrid decentralized exchanges for ERC20 tokens and decentralized exchanges for derivatives trading:
pragma solidity 0.4.15;/// @title Exchange Interface — Facilitates interaction with decentralized exchanges;
/// @author Gabriele Rigo — <gab@rigoblock.com>interface Exchange {// EVENTSevent LogFill(address indexed maker, address taker, address indexed feeRecipient, address makerToken, address takerToken, uint filledMakerTokenAmount, uint filledTakerTokenAmount, uint paidMakerFee, uint paidTakerFee, bytes32 indexed tokens, bytes32 orderHash );event LogCancel(address indexed maker, address indexed feeRecipient, address makerToken, address takerToken, uint cancelledMakerTokenAmount, uint cancelledTakerTokenAmount, bytes32 indexed tokens, bytes32 orderHash );event LogError(uint8 indexed errorId, bytes32 indexed orderHash);// NON-CONSTANT METHODSfunction deposit(address _token, uint _amount) payable returns (bool success);function withdraw(address _token, uint _amount) returns (bool success);function fillOrder(address[5] orderAddresses, uint[6] orderValues, uint fillTakerTokenAmount, bool shouldThrowOnInsufficientBalanceOrAllowance, uint8 v, bytes32 r, bytes32 s) returns (uint filledTakerTokenAmount);function cancelOrder(address[5] orderAddresses, uint[6] orderValues, uint cancelTakerTokenAmount) returns (uint);function fillOrKillOrder(address[5] orderAddresses, uint[6] orderValues, uint fillTakerTokenAmount, uint8 v, bytes32 r, bytes32 s);function batchFillOrders(address[5][] orderAddresses, uint[6][] orderValues, uint[] fillTakerTokenAmounts, bool shouldThrowOnInsufficientBalanceOrAllowance, uint8[] v, bytes32[] r, bytes32[] s);function batchFillOrKillOrders(address[5][] orderAddresses, uint[6][] orderValues, uint[] fillTakerTokenAmounts, uint8[] v, bytes32[] r, bytes32[] s);function fillOrdersUpTo(address[5][] orderAddresses, uint[6][] orderValues, uint fillTakerTokenAmount, bool shouldThrowOnInsufficientBalanceOrAllowance, uint8[] v, bytes32[] r, bytes32[] s) returns (uint);function batchCancelOrders(address[5][] orderAddresses, uint[6][] orderValues, uint[] cancelTakerTokenAmounts);// CONSTANT METHODSfunction getOrderHash(address[5] orderAddresses, uint[6] orderValues) constant returns (bytes32); function isValidSignature( address signer, bytes32 hash, uint8 v, bytes32 r, bytes32 s) constant returns (bool);function isRoundingError(uint numerator, uint denominator, uint target) constant returns (bool); function getPartialAmount(uint numerator, uint denominator, uint target) constant returns (uint);function getUnavailableTakerTokenAmount(bytes32 orderHash) constant returns (uint);
}
You will be able to find the code also on our dedicated github repo, for easier readability.
Maybe people do not feed the urgent need for such standards right now, but we are sure that the applications that are built in the most abstracted way, will benefit higher scalability later in time, as they will be able to communicate smoothly with third-party applications.
The interface we have shown states which ones are the functions that an exchange should implement. An exchange could decide to just apply some of them, of all of them. But for sure, the way of aggregating inputs by our interface, will allow users create the most different exchanges. And of course this interface is compatible with the 0X protocol, as that is the base it has been extracted from.
We believe that any type of exchange may be built on top of a generalized exchange interface. As a further example, we believe an exchange for participating in crowdsales/ICOs could be built on top of this standard. We see a bright future for decentralized exchanges ahead, the path towards a truly global financial market.
RigoBlock is a blockchain software provider focused on serverless applications for decentralized pools of tokens and decentralized exchanges. You can find more on our website.
