Mapping the Labryinth

In this article we will briefly reveiw the general types of application deployments to choose from and different types of applications that are interesting to build. Then we will propose a debate game application called the referee, the heart of the article. Finally, we conclude with a succinct analysis.

General Types of application deployments

• App-chain- You have an application or an idea for a suite of applications and would like to guarantee sovereignty or a notion of it for your community who can hard-fork via social consensus should conflict arise. The Cosmos SDK is battletested and comes with IBC & Tendermint, some of the most battletested protocols in crypto. This could also be a rational L3 deployment and benefit from Ethereum’s liquidity.
• Smart Contracts - SC dapps inherent the security and limitations of the chain you deploy on. As an SC dapp you can focus on a specific PMF for your product. There are also robust security frameworks for auditing and formal verification for more mature languages like Solidity. Cross-chain communication amongst different instances of your dapp fragments liquidity and introduces new trust assumptions.
• Universal L1 - High DA throughput for specific needs like CLOB, on-chain gaming, Social Media, et al. The death spiral risk is acute early on but persists through the chain’s lifetime. Unknown attack vectors. Difficulty boot-strapping a community. Difficult to bootstrap inital token liquidity without venture funding.
• Rollups - Rollups move computation (and state storage) off-chain, but keep some data per transaction on-chain. To date, much of the work here focuses on building EVM equivalent rollups though formidable alternatives exist. A key distinction of enshrined rollups aside from on chain da and proof verification is the censorship resistance mechanism. Users have the ability to exit enshrined rollups to L1 via forced inclusion txs, escape hatches, or proposing blocks. Soveriegn rollups rely on social consensus or some form of governance to upgrade via a hard-fork. Both types of rollups can use fraud or validity proofs to guarentee/enforce the validity of the rollup, that its execution is compliant with the state transition function,
  ${\sigma }^{\prime }$
  $=$
  $\gamma$
  $($
  $\sigma$
  $,$
  $T$
  $)$
  • where
    ${\sigma }^{\prime }$ is the new state
  • $\gamma$ is the state transition function
  • $\sigma$ is the previous state
  • $T$ is a transaction

Specific types

For brevity, I made a non-inclusive list of the different ways a developer could architect their application (there are potentially many more not listed), first partitioning the trade-off space between shared security and sovereignty. Why? This is always a hot topic of discussion whenever the notion of economic security pops up. Its also a fundamental distinction.

What to Build?

• nftFi, the marraige of Defi and NFTs, has yet to settle on core primitives with respect to trading, borrow / lend, LP, yield aggregation, or derivitives trading.
• Insurance prediction markets could enable on-chain creditDefaultSwaps which would be helpful for DAOs or even average users to hedge counterparty risk in an open and liquid market.
• Gamified social media. These types of games could be played on chain or off-chain as well but require strong sybil resistance mechanism eg. attestations from Sismo.

The Referee

The referee is a debate game with an interactive ai bot (the referee) who coordinates, arbitrates, and scores the game between players. Players can initiate a debate by opting into the game. Once the players are confirmed the first tweet pointed at the referee initiates the game.

The referee arbitrates or officiates the debate. Ideally the referee can be trained on all tweets by the players and their twitter bubble for context. In addition the referee is trained on all of the relevant subject matter. Latency may not be an issue as debate on bird app are not tit for tat in real time.

The players can pre-set a set checkpoints to call the referee to reveal any incorrect statements and assign a probability to each player winning the argument currently and if extended. If all players agree they can send a tweet to the referee ‘end’ to end the match.

The referee would produce a summary of checkpoints and a final scoring for win probability and accuracy percentage of factual errors. The referee may have to be trained in advance requiring some custom product spend and probably requires a hefty spend on servers.

You could even have the bot produce a ZK proof which proves its checkpoint updates and final score were computed correctly. Maybe you could also prove that the referee was trained on the appropriate set of information and not giving you a bs response.

Another iteration of the game would allow players to privately enter the game but prove things about their account eg. how many followers, what communities they frequent, etc. This way people who want to keep their opinions separate from their identity can do so credibly. The Privacy feature would most likely enhance richer discourse and maybe eliminate the need for people to spin up anon LARP accounts.

Many people may hate this game and not play. But the intuition behind the idea is that AI can be a terrific arbitrator for human discourse if trained correctly. I Will think more about this, but these are the type of applications I'm interested; apps that make learning, writing, debating , etc. fun.

Conclusion

Each of the application constructions listed above have tradeoffs which we briefly touched on. Many of the claims about what is important in making these decisions ring hollow and are not certain to be considered by all application developers. Social status and cultural relevance also play a role. Instead of arbitrarily looking at the above list of complex abstractions and making a biased decision, it is preferable to start from first principles by defining the endgame of the application and then working backwards to select the infrastructure it will be built upon.