AXE - amark/gun GitHub Wiki
This is the very first public document about AXE and is intended as a prototype draft for developers to provide feedback on the architecture. This page is not ready for general readership though, and will be entirely rewritten in the future.
Yes, we're notorious for our comic strip explainers for everything - our conflict resolution algorithm, how cryptography works, and more!
And yes, this is mandatory reading before you read the actual whitepaper. Check it out here:
Here is a 5 minute lightning talk that I had the honor of doing before Bram Cohen, Inventor of BitTorrent, at Berkeley.
It focuses on providing a brief explanation of how the Proof of Propagation algorithm works.
It is highly recommended you watch it before reading the whitepaper.
https://www.facebook.com/BlockchainatBerkeley/videos/2006069823011271/ (starts at 12:26)
The actual whitepaper is hosted here:
However, we will be moving it to our new website when we launch it and officially hosting it there for future reference.
It is split into 2 papers, the first on AXE itself, the second on how GUN works. Why? Because what we claim to do in AXE is impossible unless you know how GUN's CRDT algorithm works. These two things unfortunately cannot be separated, especially since many people will hear about AXE without knowing about what GUN is.
The whitepaper is in a review draft, and may be inaccurate or incomplete in areas. We would greatly appreciate pull requests on the paper, especially little things like filling in the citation links, and stuff like that.
I have answered a ton of follow up questions already in person and over email, they mostly repeat a lot of information that is already in the paper, however they also provide a lot of valuable nuanced details that the paper does not go into. When I have time, I hope to dump those questions and answers into this wiki page, and then it would be useful for the community to help merge them into the official whitepaper so everything is in one place.
Pull requests would be greatly appreciated (see comments above), however the whitepaper itself is in a google document form. So here is how to contribute a pull request:
- Open a PR or issue with "AXE:" as the title.
- Describe which Section & Sub-section you are editing. (Not page number!)
- Provide your changes as a whole paragraph or paragraphs. (Clearly marked start/finish)
- It would also be nice to provide what the previous version was (clearly marked start/finish) to prevent any conflicting simultaneous PR/changes with others.
Your contributions will be recognized in the paper in an acknowledgements section.
In the future we will probably (if needed) migrate the paper PR/issues into its own repo.
AXE will be developed in three (3) stages:
- (✓) Assume main relay peer, optimize for best bandwidth based off of browser subscriptions and "cutting off" relaying unnecessary data. Implemented: see @rogowski 's
axebranch PANIC tests! - Optimize for peer/relay-peer failover or too many peers, form stable radix DHT across all peers.
- Turn on end-to-end encryption and contracts on bandwidth/relay, tokenize bandwidth by metering throughput, etc.
SEA is a necessary primitive to AXE, and it is already in alpha.
We have working demonstrations of AXE's identity/wallet system running on a fully P2P social networking dApp and automated load tests (using PANIC) for it across a physical test network here:
Obviously, there is a lot more work to be done though. So I apologize in advance that this section is somewhat sparse other than showing that demonstrations of AXE already exist and work (this is important, since most cryptocurrencies are just vaporeware), but we will update docs with more details later.
Additionally, it is fun to note that we're recognized by GitHub as #2 in Blockchain!
Please join the chatroom to discuss things further! Cheers.
- Will latency increase when trying to establish connections?
Not noticeable by humans.
Especially during Stage 1 and Stage 2, where most of it is proxied via existing TCP/websocket/WebRTC connections anyways, the setup cost is virtually the same.
- How can tokens be traded on an exchange if they all have different value?
Using cartoon analogies, this is how tokens can be converted on exchanges:
1) Imagine creating a new physical vault, each one must have the same size of space inside.
Analog: This makes a static block, like with Bitcoin, that can be ERC20/other compatible and traded on exchanges.
2) Now, dump a ton of your coins into the vault, such that they fill it entirely.
Each one of your coins might have a different value. (a USD dime, penny, quarter, nickel, etc.)
3) You add those coins up and promise to sell the vault as a whole at a guaranteed price for the next hour.
Analog: This would be through a smart contract, timing can be adjusted.
4) Now other people can choose to buy your vault in a marketplace.
They can add the coins up themselves to verify the price.
The coins' worth might go up, down, or stay the same.
5) If they buy, the vault unlocks and all the coins spill out into their ownership.
6) If nobody buys, the time vault's smart contract expires, and the vault opens up and you get your coins back.
If you still want to sell, repeat this process (potentially adjusting the price where needed).
Some comments about AXE from the chat room:
(1) if an attacker pays for $100 for 1TB and starts sending from 1 machine, this takes some time. Let's go ahead and IGNORE the faster CRDT checks that can pre-empt this and go with the SLOWEST check (a blockchain). There are blockchains that can resolve in 0.5seconds (terribly slow!), a relay can check that either BEFORE transmitting & reject or DURING and determine that the $100 is a double spent within ~1s and having only sent ~20GB of 1TB and cancel. A couple things to note here (A) it actually costs me $0 to transmit 20GB on some of my in-production relays, so the only money I have lost is lost opportunity of having served somebody else but possible there is no other demand. (B) Holy freaking cow, if the attacker uses a real $100 coin, they definitionally are not an attacker!!!! I just made $100!!!! even if the intent of the attacker is to DDoS something! Right, I don't know what they are doing with the data, it is probably encrypted! (C) Finally, remember, this is the INVERSE of the current ISP model that incentivizes DDoS, if I am a relay and I get DDoS by somebody paying me to send data through me... guess what happens? My socket with them crashes! And I get disconnected on the pipe and fail to fulfill transmitting the data... but woops, I just got paid $100? So that makes me the malicious party! So I can either refund or keep it (and then lose it in the court system).
(2) ... if the attacker actually wants to attack the system, they'd send it in the tiniest payments they can as many as they can, < $0.01 at 10K payments. But this is physically difficult to do, 1 connection between 2 CPUs has to process things sequentially, so let's again assume we ignore the fast CRDT checks and depend upon the slowest check of a blockchain, and assume since this is not a high value $coin I'm lazy only check during transmission not before and it takes 10 seconds, I'll at max "cheated" on 10GB (vs 20GB on the other one) of thruput, which again (A) & (B) & (C) doesn't actually cost me anything other than opportunity loss (other peers) BUT (D) relays cater to highest offers in first place, so this has to be my "best chance" of getting money. So this leads to the real way an attacker should attack, which is to do < $0.01 10K payments across 10K machines, each concurrently simultaneously connecting to my 1 machine, this then breaks into 2 categories: I either (Z) can't handle that much concurrency and those sockets get crashed/dropped and woops maybe now I'm the cheater keeping the fake-double-spent money that they didn't get a PoP on or (Y) I relay all the data $100 profit (but not loss to me, see earlier comments) & find out 10 seconds later they're double spent & then auto-submit to court & 20 seconds later get a refund.
(X) Wait, how does this magical refund work? Well watch the talk. The only way you cannot get a refund is if the attacker only had $100 in their account and drained it all in the 10K payments. But wait!!! This is the beautiful secret I've been pushing aside "let's assume the CRDT & faster methods are not checked, we only use a slow blockchain"... the CRDT can check account balances & other meta data extremely fast (I've seen as fast as 80ms round trip global response times for my browser, for a relay peer this could be sub < 8ms) and peers by default will be configured (each can set their own risk tolerance, or dynamically change based on market pressure/demand/opportunity gain/loss, etc.) to require at least 10X+ funds in accounts than the current payment (or specifically, X * timeToValidate), which would be approximately $0.10 per 10K accounts ~= $1000 the attacker has to have in funds in advance.
(F) But now think about this last part. How do they get funds in their account? They have to fund it, which itself is a process that takes time & validation, so by the time a relay even uses the CRDT check (8ms, if not 0ms from GUN caching) then it can safely be assumed that the "attacker" has real (non-double-spent) $1000 (not $100) worth of coins MINUS the time difference since the last validation. The larger that gap of time is, the more conservative I should be in checking first rather than checking during relay. The shorter that is, the more eager I can be about out-competing the countless other relay peers in the DHT. The other option of how they can get funded, is if they provide bandwidth (are a relay), but that is easy to determine of lying/colluding on $100-worth, because if they faked it their coins would be at +978th generation from the on average generational coin circulating, OR if they legitimately relayed that much data within Y amount of recent time (the longer ago it is the more risk they've been double spending in meanwhile, but also proportionally higher chance they've gotten flagged for trying to double spend any 1 coin), but to divide that much bandwidth credit up over 10K accounts itself takes time to do (which allows more time to detect) OR they have to do the attack from a single machine, which now just circles all the way back to where this began at (1) with worse case settings of: Either it is real money (yay I profit); I've screwed them over and they get a refund (boo, I'm the bad guy); or cancel 20GB / 1TB and I get refunded. Why do I get refunded? Because of (X), now we've just circled back to (X). How can we trust (X)? Because of this, (F), but if (F) passes it is hard to do (1) or (2) in the first place unless you legitimately have real money to spend, which in my case, I profit, not get attacked!!!