# Notes on blockchain things, 01/01/2023

## TL;DR

Improving blockchain UX is probably required before we can do much else with them, and
Deku v2 seems like a good next step towards that.

## Worthy Goals

1. Censor- and seizure-resistant money
2. Lower the trust required for people to contract with each other
- I.e access to smart contracts
- I.e access to better governance (DAO's, new voting systems, etc.)

## Worthy Subgoals

1. Improve TX infrastructure and UX.
1. Waiting 15-30 seconds for TX confirmation is bad UX.
- Speculative execution is possible, but much too burdensome to build yourself for
small apps (which might explain why there are no small apps).
2. Even the nice wallets are still way too involved to use in an everyday sort of way.
- Beacon network is really nice. But there are so many little steps involved that
you will lose users just on that basis alone.
- For small apps (workout tracker, todo list, etc.), I don't want to go through
all the wallet steps on every single transaction.
- A solution is session keys like we've implemented for Deku-plays-pokemon and Decookies, but right now you have to implement all this yourself.
- Making users pay for gas is needless hurdle to adoption.
- It means I must spend money to use _any_ app, even if that's not required for the app's business model.
- 99% of the time this will be through a KYC centralized exchange.
- It makes managing session keys from above more complicated, since I must
pre-fund each key.
2. Make it super easy to develop apps on Tezos
- E.g. SDK's and frameworks.
- E.g. standards and protocols.
- Note, this goal presumes that there are great apps for Tezos in the first place. I'd like to prove this by coming up some with great apps for Tezos.
3. End-user Programmable Money
- I've hugely benefitted from https://qubemoney.com/ - it's the first app in a long time
where the benefits without doubt overwhelm the drawbacks.
- It's an FDIC-insured bank with an integrated budgeting system. Every bill gets its
own Visa number, such that the accounting is done automatically for you. And for
every ad-hoc purchase, you select the line-item in your budget to deduct from to unlock the funds, so there's no accounting necessary after the fact. At all other times,
the spending account is zero-balanced, meaning you never have unexpected transactions.
- Qube provides end-user programmable money, but the only only operation is creating buckets and moving money into them. One could imagine going much further:
- Selecting from pre-made budget strategies vetted by experts and the community
- Automatically accounting for taxes, etc.
- Eliminating the need for accountants in the easy cases, and giving accountants
more leverage in the harder cases.
- In principle, this application would be so much easier on a smart contract platform like Tezos! Except:
- No goods or services are denominated in crypto
- Crypto is volatile and stablecoins aren't widely available/used
- Wallets are unforgiving and foreign, making them too risky for most users. We need
social recovery, etc.
4. Give people better access to better governance
- Vitalik explains there are different governance goals
- efficiency - able to rapidly and precisely change according to desires of constituents
- robustness - hard to kill (usually implies slow to change)
- interoperability - matches some target DAO, etc.
- Making it easy for people to use new governance tech would be great.
- But governance without a killer app seems like putting the cart before the horse.
The ideal would seem to be "Here's a killer app. And btw, it's governed in this more efficient or robust way.".
- It doesn't seem like governance _is_ the killer app itself. Else, wouldn't Tezos be king already?
5. Stable coin
- Why? Because volatility makes it hard/impossible for normal people to use crypto.

## Low hanging Tezos Fruit
1. Allow multiple manager operations per block. (See [Arthur B's post in slack](https://tezos-dev.slack.com/archives/GB0UR34N8/p1658377244547899?thread_ts=1658367890.473719&cid=GB0UR34N8)).
2. Instant finality via bonded baker receipts
- Marigold had a PR for this at one point
- I asked about it in a [slack thread](https://tezos-dev.slack.com/archives/GB0UR34N8/p1670882620423149) recently and there was some discussion.

## Possible Projects

Just ideas, not necessarily good ones:

1. Improving wallet recovery
- credit: https://vitalik.ca/general/2021/01/11/recovery.html
3. Start a bank
- could be a venue to solve many of the problems listed in "3. End-user programmable money"
4. Twitch Plays Pokemon
- The Deku POC is live on Twitch now: https://deku-plays-pokemon.surge.sh.
- This is still a great demo for Deku v2
5. Tezos messenger app
- possibly on Signal or Keybase
- Signal already uses
- possibly including a message board
- prior art: https://chat.blockscan.com/start
- Grant RFP:
> Solution that allow Tezos stakeholders to message other stakeholders using Tezos addresses (public key hashes) while paying attention to spam and confidentiality, including the confidentiality of metadata.
- Possible scheme for metadata privacy: [Fuzzy Message Detection](https://eprint.iacr.org/2021/089) (see gist further down)
- See 9. for spam prevention.
6. Build a game on Deku or a rollup
- Or use state channels. State channel infrastructure would be great to have for Tezos games.
7. Build a TzStamp browser plugin and javascript thing
- A browser plugin that queries TzStamp could provide trustworthy attestation
of the author and publication date of an article on the web.
- We have to shift public opinion to require such things, but we did it for HTTPS.
Maybe crypto-aware browsers like Brave and Opera could provide this out of the box.
- We would need blogging and website tools to have built-in integrations with TzStamp.
8. Tezos Domain Service tools
- Like fleek https://fleek.co/
- Something like this should have an integration with tzstamp
9. Spam prevention as a service
- We can offer a range of things depending on the use-case:
- put money on the line for your identity
- use hard-to-spoof social proofs like Benjamin did
10. Productionizing Rollups more
- Make it super simple to develop and deploy rollups on Tezos
11. Build code-gen tools for Ligo
- input your ligo smart contract => output typesafe Typescript bindings/Go bindings/etc.
12. Build toolkits for Tezos in all the languages and frameworks

## Notes on my experience creating a Tezos app

- Goal: make and keep commitments over time with help from friends
- The idea is form a commitment and get some friends to help you keep it/keep you accountable
- Example commitment: work out every day
- Every day, you keep your commitment and signal you did with a tx
- You put some money at stake - if you fail to keep the commitment, it's burned (or goes to your friend, or ... ?)
- Your friends can release you from the commitment, allowing you to get your money back
- You can quit without being released. You'll get your money back, but an on-chain event will
be emitted "so-and-so is a QUITTER"

I finished an MVP of the app, and I've been using it every day.

BUT! I had a _lot_ of problems making this app:
- The Ligo code was really hard to write. (GA: I sent you my list of problems in a slack message earlier)
- When I showed my wife, she was like "I would never use this because the [airgap wallet] setup is so complicated"
- Even when wallet setup is complete, it's many steps to complete a transaction
- So implemented a subkey system, like we did for Decookies
- But this is more complicated on Tezos! Becuase you have to prefund the account,
so it's even more steps!
- Also, Taquito isn't set up for this, nor is beacon, so it's kind of awkward to do.
- Even with the subkey system, UX is bad because the confirmations are so slow!

Possible Solutions:
- Make Ligo more reliable (I'll do my best to continue reporting bugs)
- Implement a standard + protocol + Ligo library + infrastructure for session keys
- Implement speculative exection standard + infrastructure
- Implement better wallet onboarding
- maybe something like: https://magic.link/

## Notes on the Competitor blockchain Sui
https://docs.sui.io/
- Focused on low latency
- Two consensus layers
- One for Byzantine Reliable Broadcast based on [Fast Pay](https://ieeexplore.ieee.org/document/8567700/)
- AFIU the idea is that you often don't need total order on TX for safe.
- When a partial order will do, need far fewer rounds of communication per TX => less latency
- It's much more straightforward to do parallel in this execution since it falls out of the partial order
- One for State Machine Replication: Narhwal and Bullshark
- This is the tech ZFX was working on.
- AFAIU the idea is that you can separate data availability from consensus. By building a DAG of messages with
your gossip layer, you can do consensus on top of it with less messages and lower latency.
- New smart contract language: Move
- Seems focused on resource management and safety
- This makes it easier to do parallel execution, and more transparent what operations will be parallelized.
- One thing is clear: this a more complex system.
- They admit in their docs that two consensus layers adds a lot of mental overhead.
- But maybe they can afford the complexity budget?
- The folks involved started this research at Facebook Novi, then Diem, and now Sui, so they've had lots of
time to refine this stuff. It looks like this version of Sui might be the 2nd or 3rd iteration of this tech.
- They did not answer my questions about consensus and throughput, etc. :( I'll try again a bit later (people may still be on holiday)
- They have a lot of money
- $36KK Series A
- $300KK Series B (led by FTX Ventures, lel)
- It really shows in the polish:
- They have a docs team. Their docs are beautiful and clear
- Their online communities (Discord, forum) seem very actively managed
- Aside: I really like how their discord is organized, and we could easily copy this. For example, they use
permissions more extensively to promote higher quality discussions, and they have channels that act as
announcement streams for new developer tooling and learning material, etc.
### Thoughts
After looking a bit more at their stuff, I came to the conclusion:
- I need to understand consensus better before tackling L1
- I still don't have a good grasp of the available tradeoffs, and I think looking
at more systems will help with this.
- Narwhal/Bullshark look very nice
- Edward Tate was very interested in Narwhal/Bullshark. I trust him to do his
research on this stuff.
- The DAG+zero-message overhead consensus is a lot like where Edu wanted to take Deku.
- The informal papers I read indicated that the engineering is simpler in this scheme
as well.
- At the same time, it's unclear if this stuff matters
- As GA has mentioned several times, consensus is not the bottleneck for throughput,
and throughput is very low right now.
- We might be able to achieve reasonable throughput without these more complex schemes
by making tradeoffs in decentralization/fault tolerance (like the Rollup + DAC model)
- Even if Sui's consensus and smart contract engine were strictly better tech, there is probably still space for something with different complexity budget strategy.
- Hence, Deku v2 as Rollup + DAC seems more interesting to me than a L1 right now,
since the solution differentiates itself with a very different set of tradeoffs.

## Gist for the Simple version of Fuzzy Message Detection
This scheme allows for users to choose some false positive rate p = 2^-n for integers 0 ≤ n ≤ γ where γ is a constant shared by all participants.
- Choose two asymmetric encryption schemes
- One to encrypt messages
- One to encrypt flags signaling the message recipient
- Must have the following props:
- key-private ciphertexts
- uniformly ambiguous encryption, that is:
> decrypting an honestly-generated ciphertext with the “wrong key” produces a random plaintext
- These two could be the same scheme.
- To be alerted of new messages, users must create detection keys shared with a server:
- Choose some false positive rate p = 2^-n.
- Generate γ public/private key pairs
- Combine all public keys into a detection key detection_pub = [pub_1; ..., pub_γ]
- Share some subset of the secret keys [sk_1; ..., sk_n] with a server it will use as detection keys.
- For Alice to send a message to Bob:
- Alice encrypts her message to Bob's public key message encryption key
- Alice encrypts the bit "1" to each of the keys in Bob's public detections keys.
- Alice delivers the message cipher text and detection cipher text to a server
- For each registered user, the server attempts to decrypt the detection cipher text with
its subset of the detection keys. Whenever all yield "1", it signals the user.
- Something I'm still unsure about is the safety of the metadata over time - without
cover traffic, is Alice's communication with Bob always ambiguous?