jl777 (OP)
Legendary
 Offline
Activity: 1176
Merit: 1132
|
 |
November 27, 2016, 04:52:54 PM |
|
I just released a pre-release candidate version of komodod. All of the identified hardfork changes are active, including the assetchains decentralized gateway with pricefeed.
I added anti-tampering to the pricefeed, and extended the notarization data to include approvals for withdraws. Additionally, there are limits on the total amount of each fiat that can be created. For now it is set to 10000 to 40000 fiat units per fiat. This limits the total worst case exposure to the blockchain to a small enough level. with pax2, I will activate methods that allow increasing the total allowed while maintaining the max exposure, but first step is to get the fiat cryptos in active use.
I also use the implied KMD price from BTCD conversion in the paxprice calculation. I know there is a strictly limited amount of BTCD available at below ICO prices, but it is what it is and as long as it is trading, whatever price it calculates to is a least more tangible than random guesses. Of course, with the limited liquidity, we get the silly result that marketcap goes up 10% with each 30BTC, +40% with 90 BTC and 333% gained with 150BTC.
So dont take the implied price as any stable way to calculate marketcap, it is just a very rough estimate subject to limited liquidity
I have submitted a draft of the PAX technical description a while ago, but I didnt describe the details of the decentralized gateway, even in that document as there were some issues I had to solve during the implementation. Now that it is complete, I am able to accurately describe it.
I wont go into all the details about the price feed as I already wrote that in the initial document. For here, just assume that we have a reasonable stream of prices coming into the blockchain. By reasonable, I mean that more than 51% are valid prices.
In order to calculate the KMD <-> fiat price conversion we need to know 3 prices: KMDBTC, BTCUSD, fiatUSD (for USD only 2 prices are needed). I use BTC and USD as reference currencies as they are the de facto reference currencies used in the markets.
For the KMDBTC and BTCUSD prices, a method similar to augur is used to get a deterministic but random majority correlated price for each height. This is then price smoothed over the prior day (with a pseudo-random starting point in a circular buffer). Then the same process is done with the derived fiatKMD price, so in order to game the system, the majority of pricefeed samples need to be controlled, which requires control of a majority of the notary nodes. Due to the four-way geographic split and wide voter base for the notary nodes, we dont expect that it is practical to get majority control of the notaries.
However, as a precaution there is a max limit for each fiat allowed, so in the worst case the damage is limited. Until the dynamic rebalancing of pax2 is active, this will be sufficient to prevent any runaway scenarios.
So we can assume that for each height, we have a deterministic price consensus that is not gameable for all 32 fiats. I believe Komodo is the first to achieve this. But this is just the start of PAX! In order for PAX to work, the pricefeed needs to be converted to blockchain enforced coins. The general concept of how to do this was introduced with the multigateway (MGW) that I did almost 3 years ago, but going from a distributed MGW to a decentralized gateway required some complex steps.
Namely 5 steps.
1) paxdeposit: this is the process of creating new fiat coins dynamically by converting the corresponding amount of KMD into the fiat coin. This is achieved by burning the KMD in an OP_RETURN, which includes the specifics on prices, fiat, etc.
The KMD side is straightforward, the trick is how to convert that OP_RETURN burn into an issue of the fiat coins in the fiat assetchain. Before we can even think about doing this, we need to solve how on earth can many blockchains know the state of the other blockchains!? It is not practical to use the RPC due to performance problems when dealing with dozens of chains.
I ended up having to create a special komodostate file that records each event in a file. This allows all instances to parse the komodostates of all the other chains and thereby reproduce the identical state in all 33 chains. It was a lot harder than it sounds to get it all working stable.
2) Issue: So, given that, the fiat chain can "see" the OP_RETURN burn and when it does, it tracks which ones have been issued. Things happens all out of order, so we also need to know when we are all caught up to realtime states in both chains as we dont want to do any duplicates. It is the miner that actually does the query for any deposits without the matching issue. All the miners on all the nodes see the same pending deposits (we are in consensus after all), so regardless of which node mines the next block, the pending deposit is issued.
The way I issue the fiat coin is to extend the coinbase transaction with extra outputs, along with a summary OP_RETURN. When this is seen (on all nodes for all chains), the deposit is marked as completed so it wont be duplicated.
Now the fiat coins are issued at the appropriate price, once and only once. Note that the same method can be used to create a sidechain, just remove the pricefeed and do it 1:1
Believe it or not, this is the easy side of the decentralized gateway. The reason is that all assetchains have to run komodod, so we can be assured that all nodes running EUR chain has access to the realtime komodod state. However, the reverse is not true. Not all komodod instances will have access to the current (or any) fiat chain instance, since a user can pick and choose which assetchains to run.
This assymmetry creates quite a lot of potential issues. Once approach is to use the segwit method of having two classes of nodes, the updated segwit ones that are able to validate transactions and the other nodes that just need to trust the segwit nodes to validate. With enough nodes running to verify things, it might be acceptable, but we have notary nodes, so I decided to enhance that level of security with a notarization of each withdraw. So there is a withdraw, approval, redeem on the conversion of fiat coin back to KMD.
3) paxwithdraw: nearly identical to the paxdeposit, just done on the fiat chain side to create the OP_RETURN burn of the fiat coins.
4) approval: notary nodes add paxwithdraw details to the notarized data. All nodes that run both komodod and the fiat chain are able to verify that the paxwithdraw details in the notarized data are valid. This means we get the segwit level validation enhanced with notary node consensus on the withdraw data. Now even a node that is only running komodod gets almost as reliable data as actually running all the fiat chains.
5) redeem: all nodes that are mining gets the pending withdraws (using paxpending RPC) so whichever node mines the next block, the redeem is issued properly. Once and only once. All the nodes are able to validate using the approval data or the data directly from the fiat chain.
One final thing which we shouldnt forget is to make sure that prior to 2) issue, that it is notarized. this way fiat coins are issued only after they are notarized in btc chain. On the return side, since we are piggy backing on a notarization, we get the benefit of notary node consensus for the redeem.
Hopefully the above answers all the questions you have had about how on earth can pax possibly work.
Next up is to verify the iguana notary dapp is updated to match the komodod. I think it already is, but need to verify it. iguana notary dapp changes can be made without a hardfork, so it is less priority than komodod changes that would create a hardfork.
The pre-release candidate isnt a release candidate as I am waiting for zcash to release 1.04 so I can rebase to it. That is expected next week, which is good timing as it will likely take a week or so to verify the assetchains.
With fixing any bugs in the above as priority, I will be shifting to porting the DEX to the notary nodes and getting it integrated into komodod so iguana and komodod can cooperatively DEX. This wont be hardfork changes to komodod, so it can happen even after the initial mainnet version is out, but I prefer to get it done prior to it.
I am ready to do REVS snapshot at any moment, but due to popular demand to allow people to participate in the snapshot without any local wallet, we are updating the ICO site to allow for this and this takes time. I am not personally working on it, so please dont ask me its status.
I believe the current PAX is the first implementation of a decentralized gateway, especially one with an external price feed. By using the notary nodes, it becomes possible to do things that otherwise would not be possible to do. Komodo is thus able to continue to be enhanced with what otherwise would require centralized servers, but instead of that, Komodo can use the notaries + decentralized methods.
PAX proves that it can be done, but it is just the first of such a hybrid functionality to be active.
|
