cryptoeconomics-study / visualizations Goto Github PK

Clean Homepage describing the course, with youtube link. Button to start course opens up what we have now.

• Check visible content to serve correct interactive
  • possibly just have all information in individual cards, and have scrolling up/down switch to next or prev card.
• Check visible content to introduce relevant information/tooltip/functionality within interactive
• Table of contents
• Show chapter in top bar

Currently deploys into https://k-ho.github.io/code/, but would be better if deployed to something like https://k-ho.github.io/consensus

Clean up CSS for a cleaner look/feel.

• Improve buttons

• Improve background color,

• box shadows/ maybe rounded corners,

• fonts

Allow a slider from 0 to 100% that allows for user to specify % of packets that get dropped

• Add Gerbil picture to title of Ledgers

• Use Gerbil pictures for balances instead of addresses

When clicked, nodes start to send out consistent transactions . When paused, nodes stop sending transactions.

Make invalid nonce transactions maintain order by time received. Currently iterating through an object's keys, so the order gets messed up whenever a new invalid nonce tx is received.

Remove right sidebar. When click on a node, have a box appear in controls with:
"Double spend"
"Send a Transaction"
"Show State"
Clicking "Show State" creates a pop up box in the top right corner with the Node's address and state.

If you click very fast repeatedly on a node, the simulation pauses. If you then click pause and play, it starts to play again. Weird...

On mouse over message icon: Create popup with image like one of these:

If mouse is inside the popup, keep it around, as soon as mouse leaves the popup, remove it.

Redux could be a better way to manage state, since we pass so much information in as props and have a bunch of passed in functions that we call (e.g. functions passed in from Network.Js to be called by the buttons in controls.js)

Click Pause -> button says play
Click play -> button says pause

List of transactions, seeing it's timeout + how many signatures it has received. Best way to show this may be just on Hover of the message...

We could demonstrate timeouts well by having a string of nodes, and having a message travel from one end of the string to the other, with a table that shows the node's timeout being bumped up as signatures get added.

• Currently nodes/links float around even when the network sim is paused, but messages stay in the same position.

Clicking on a node should give the option to take a node offline or back online
Example: https://raft.github.io/

Clean up react-d3-graph so we only have the minimum amount of code for our visualization to work.

• Move Graph components into a single "Graph" folder
• Remove unnecessary files

Can probably do this with controls.js. "It is a good practice to use functional stateless components whenever you can." (Source)

2 sliders for min and max, have reset button and apply.

When a node is bankrupt (Balance: 0), the spend/double spend buttons should either be disabled or should have a "insufficient funds" pop-up on click.

Create a tray with gerbil pictures. Gerbil face is disabled/greyed out if that Gerbil's ledger is already showing. otherwise, clicking on a Gerbil's face will show their ledger.

(optional) Tray can be minimized.

Here's an example of using d3 transition to animate along an svg path. Definitely better performance than our current animation: http://bl.ocks.org/KoGor/8162640

I think the above is the best option, but if we end up needing to use react for animation, here are the top react animation libraries: react-transition-group, react-motion, and react-move

Toggling ledgers doesn't work while paused. Once simulation is unpaused, the changes are made.

• Create simple home page with links
• Links direct to custom URL, urls choose which sandbox to display

Currently, messages are rendered as nodes:

Render messages as a separate array of "Message" Components. Create a "Message" Component. When you click on a message, can show an info box about the message.

Using something like Repl.it, users can develop directly in browser, using an in-browser terminal and text editor.

Benefits:

1. Less friction to get started. See Cryptozombies.io
2. Ability to track things like time spent on assignments, can view individual sessions and see what people are getting stumped on.
3. Can view which sections of the assignment cause users to bounce.
4. Could expand to offer hints given which function a user is working on.

Cons:

1. Less flexibility - some users love their text editor, their colors, their specific IDE.
2. If we are targeting experienced developers, they may actually prefer developint the way they're used to.
3. No source management - users won't be able to use git like they normally would.

• "Create Transaction" is a button in nodeControls (in Controls.js)
  When clicked, The button becomes disabled, and the simulation is paused.

• The simulation is dimmed (slightly greyed out), and a large bar shows up at the top of the screen that says "Select who you want to send the transaction to" (or an X button in top right to cancel transaction)

• Then a popup shows up saying "how much would you like to spend?" with a slider sort of option to select amount sent - anywhere from 0 to node.balance.

• At the bottom of the popup there is a checkmark that lets you select "sneaky mode" or "attempt overspend". If the checkmark is selected, there is no longer a cap on the amount you can select with the slider

-[ ] Optional: Then, there is a query - Do you wish to attempt to spend someone else's money? Then you can have another "Select who you want the transaction to be from"

-[ ] Then there's a button to "sign and send" that you just click

-[ ] Transaction is "generated" as an image in nodecontrols:
and animates into a node, then the transaction is sent out as colored circles as normal.

Color outline around the currently clicked node(s)

Create a visualization of the 99% Fault Tolerant Consensus Algorithm.
https://vitalik.ca/general/2018/08/07/99_fault_tolerant.html

Make the graph network render larger by default and always in an open space (center of screen)

(only visible when a node is selected)

• First, you are this node, enter your name.

• We're gonna start off by building a central payment processor. Something like Paypal. Show a new large node appear called "Paypal".

• Paypal will keep track of how much money everyone has. *Show a state table show up with Alice's name and 0 dollars. *Paypal's feeling nice today, so here's $100. See Alice's balance increase up to 100

• Sounds good. But, names don't seem like a very good way to keep track of everyone's money. What if someone else joins Paypal named Alice?? We represent every person as a different long string of letters and numbers called an address. (maybe for simplicity sake, we just use public keys)

• Let's try to send some money to Alice's gerbil friend, Bob. Alice will make a message. show message appear above alice that says "From: 0xabc (Alice), To: 0xdef (Bob), Amount: 10". Paypal receives the message and shows a green checkmark. Alice's balance decreases to 90 and Bob appears with a balance of 10.

• Awesome! Now let's see if we can be sneaky and trick paypal into sending money we don't have. Show new message sending $100 from Alice to Bob, Alice sends to Paypal. All Paypal has to do is check to make sure Alice has the money she's trying to send. Show "90 -100 < 0" in red. Error message appears "Insufficient funds".

• Let user create transactions as Alice and send them to Bob. Now, let's try something sneaky.... Switch From and To, so now messsage reads: "From: Bob, To: Alice". User sends the transaction, and Bob's balance decreases and Alice's increases.

• Uh Oh!! We have no way to check that the person sending the transaction is who they are. Enter: DIGITAL SIGNATURES!! Each user has a public key and a private key. Think of the public key as similar to a bank account number or on something like venmo, your username, and the private key is similar to your card and PIN number or your venmo password. You can use your safely kept private key to "digitally sign" your transaction, and everyone can verify using your public key that the transaction was signed by your private key. The signature is just a long number that Paypal can do some math on with your message to verify that you signed it.

• Reset paypal state to Alice: 100, Bob: 0. Now, show transactions sending from Alice with "From: 0xabc (Alice), To: 0xdef (Bob), Amount: 10, Signature: 0xa29309f".

• Let's try to send money from Bob again: "From:0xdef (Bob), To 0xabc (Alice), Amount: 10, Signature: 0xa29309f". Transaction sends to Paypal - flashes red. "Invalid signature" error appears.

• Show transactions going back and forth between Bob and Alice. Let user send $10 from Bob to Alice and sign, or send $10 from Alice to Bob and sign. But wait! There's one last attack that we didn't handle :(

• On the Internet, it's fairly easy for someone to listen in on your network activity and see the messages you send out. So if you're trying to be bad... You can listen in on the messages Bob is sending out to Paypal. Show Alice move over to the link between Bob and Paypal with an ear up to the link. Bob sends "$10 to Alice" message to Paypal. Now you have Bob's signature and his transaction information!

• Show Alice sending 5 of those transactions to Paypal one after another, and Paypal accepting them, depleting Bob's balance and adding to Alice's. The digital signature is correct, but Bob only meant to send that transaction once. Bad Alice!

• This is called a replay attack. We prevent replay attacks by adding a number called a nonce to each transaction we send out. Our nonce is just saying "This is my Xth transaction". So, if Alice tries to replay Bob's "2nd transaction", Paypal will reject it: "I already got Bob's 2nd transaction, I'm waiting on his 3rd transaction now."

• Let the user play around with 5 nodes, with transactions being sent to paypal, allowing users to attempt replay attacks, spending money they don't have, and invalid singatures.

Eventually, will get an "insufficient funds" error when someone runs out of money, which freezes the simulation.

React binds the class method every time the render() method runs, meaning every time the component updates, which will hurt our application’s performance. Binding the class method in the constructor needs to only be done once, when the component is instantiated.

Make lint pass with no warnings.

Allow multiple Node states to be opened at the same time. When adding a new state, automatically follow some ordered row/column organization, and when removing a state, automatically shuffle all popups back/ up one spot.

Have a ( ? ) button in the controls panel which triggers a popup. The pop up should contain pictures of buttons and a description of their functions.

Attempted import error: 'network' is not exported from '../../c2_NetworkDoubleSpends/Latency_Based_Consensus/createFTNetSim'.

• Title slide: Network Models and Double Spends. We now have a working Paypal implementation! That was easy. But, what happens when Paypal is bad? What if Paypal just prints free money to their homies? What if Paypal tells everyone their money is held in secure investments, but in reality Paypal has invested everyone's money in risky subprime gerbil mortgages!?

• There must be a better way, where we don't all have to trust in the goodwill of Paypal! Enter: Client side validation! What if: Everyone just stores their own ledger of how much money everyone has? If everyone can agree on how much money everyone has, then we don't need a central operator!

• We are each only connected to a few other people. These are called our peers. When we want to send a transaction, we send it out to all our peers, and they will forward the message on to all of their peers, and so on until everyone gets the message.

• With latency, this can get hairy, but we can see that if we let the messages finish propagating, everyone eventually has consensus on what the state of the ledger is.

• Play around with the simulation!

• But... what if we have a bad gerbil? What if we try to spend the same money to 2 different people at the same time? This is known as a "double spend attack"

• Show double spend attempt. (it might fail, in which case show alert "double spend failed due to network latency. Try again!"

• Look! Now the network is split into two colors, some of the nodes agree one 1 state, while the other nodes agree on an other. This is called a "Fork", like how a path can fork into two paths. If we don't all have consensus on everyone's balances, then we won't be able to interact with another.

Have a node or message flash red when a packet gets dropped.

Display list of each node's pending transactions, and when they will be applied: Ideally, some progress bar around them that denotes the timeout. Can show progress like: https://raft.github.io/

change nodes from colored circle SVGs to gerbils inside of colored circle svgs

Have a toggle switch:

1. Everyone is represented as Gerbils with names, transactions are represented as easy to view "checks" with gerbil A picture to gerbil B picture.

2. Cypherpunk mode: Dark view, with a feel like shenzhen.io. Realistic view of the network: Every node is just an address, hovering over a transaction reveals the actual transaction json object with signature. Almost like a debug mode.
   

Questions:
Should we just have a timeline to scrub through history?
Should we even have fast forward, rewind, step forward, step back?

Fix glitches in fault tolerant viz.

When messages are being constantly deleted/redrawn at every tick in Graph.jsx, they sometimes appear to flicker. This bug needs fixing asap!

Inspired by https://scrimba.com/: Store lessons as audio files with timestamped events (e.g. move curser to node, click, click spend).Our "instructor" interact with YOUR simulation while teaching it, and you can always pause and move nodes around and interact with the simulation

Using react-d3-graph contains way more functionality than we need, and is adding unnecessary complexity. I believe the best route forward would be to either greatly prune the codebase of react-d3-graph to the basics, create a d3-force graph from scratch, or start extending a much simpler library like https://github.com/uber/react-vis-force.

Think the last choice will be best + easiest