I need to owe up to something. Stating a "completely decentralized exchange for alts" in 3 weeks time, was a mistake on my behalf.
What I meant however was for bitshares pairs and assets. Again, because this can be done with the 2.0 API already.
We could possibly create a centralized exchange, but that kind of beats the purpose of what I wanted it to do.
Here is what my dev had to say.
Let’s use
https://bittrex.com/ as our point of reference and ignore the idea of needing to create a public api as they’ve done.
Before we can get implementing the bid/ask system, first we must address depositing funds. We need to create a system for each currency we intend on supporting that has some basic features: creating a new address (so we can associate it with the user), querying the balance on an address, and sending funds. A abstract driver might look something like this:
public abstract class BaseRpcConnection
{
public abstract decimal QueryBalance(string account);
public abstract void Send(string account, string address);
public abstract string CreateAddress();
public abstract void Shift(string account, string master);
}
For the majority of alts, they’ll all end up all using the same driver (the same as the bitcoin driver) since their RPC api is identical. There are however a few currencies that require individual connection classes (i.e. NXT, BTS, ETH to name a few).
All in all, this doesn’t take long, it just requires a bit of research on the alts you intend on setting up and their apis. The tedious task is setting up the daemons for each coin, but we’re going to not focus on the time that takes because we’re focused on the coding aspect of it.
Somewhere in your database, you would store the information as such:
username : string
password : string
rpcUrl : string
We could store port, but for some systems such as nxt, their end point isn’t simply the port but contains “/nxt” so it’s easier to store the rpc url.
Now when a user creates a wallet we simple need to do something like RpcConnection.Create(coinName) and then call invoke the instance member CreateAddress. There should be a background worker than scans users accounts for deposits and uses instance member Shift to move the funds to a central account (note: with Bittrex, the reason they use a memo field for NXT, BTS, etc. is because there is no internal shift or off-blockchain transaction like there is with the BTC daemon, so they make you deposit with a memo or message to avoid the transaction fee of shifting funds so it all ends up on one account).
Once funds are received, update the internal ledger (database) of how much funds they own within our system. Likewise, if they withdraw you deduct this amount from the internal ledger. Worthy of noting is handling balances with database locks to prevent concurrency exploitations.
Ok great, we can now accept funds (that obviously didn’t take too long…) the next step is being able to list ask/bid transactions. Pretty straight forward, an order looks something like this in the database:
id : int
buy : boolean (if false then sell)
quantity : decimal
rate : decimal
pair : string (i.e. BTC-LTC)
if you wanted to be more “efficient” you could take the Cryptsy approach and use numeric representations for currencies, but since it’s likely there’s like less than 1000 pairs, this is a minor optimization for loss of easy readability.
Matching bid/ask pairs and then executing orders isn’t hard, I don’t think this is really worth going into depth about explaining… literally this could be assigned as a first year computer science project.
And then boom, at this point you have a very basic exchange. Time consumption really begins to be exhausted when you want to implement supplementary features (i.e. market tracking so that you can plot the time based data on a graph.. people today seem to sure love those candle sticks) for open/close plotting (ask/bids). Another more obvious supplementary feature would be a public api.
Difficulties with decentralization:
So going back to the principal of it all, an exchange has two aspects. Storing (and executing) the asks/bids, and storing the funds. Storing the funds is the biggest problem with decentralizing an exchange, whereas the ask/bid information is simply arbitrary data that exists on a blockchain.
The reason storing funds is so complex is because this needs to be done in a way that doesn’t involve using the alt coin daemons (it would be unreasonable to have a user running all the daemons the exchange supports) but still needs to be able to verify their balances (even if a user dumps their wallet clone on the block chain, they could still spend after an ask/bid was listed).
In Conclusion:
So it’s obvious that creating a centralized exchange can be done within this timeline but a decentralized exchange is a whole different story. To say the least, if initially we start with a centralized exchange, we then end up with a working model for a decentralized platform once we’ve developed a blockchain technology that tackles the problems listed below (i.e. once we’ve created the api for the decentralized ledger/exchange, it’s only a matter of plugging it into our exchange website in place of the centralized order books and balances).
Other challenges in creating a decentralized platform involves using a cross-platform language (i.e. Java, Python, Node.js) but I’d like to heavily place emphasis on any of these languages (as well as even C/C++) are fine to use and the decision is literally up to preference and what’s easier for the person creating the distributed platform.
Topic: Reducing Bitshares Supply : A different approach (Read 11269 times)
