How about fixing legal loopholes through incentivized testing?

Watertight laws without loopholes matter and the concept of automated testing from software engineering could revolutionize how we draft them.

Read on for my thoughts...🧵

#LawReform


https://twitter.com/hiddentao/status/1776167743236034609

The issue with the drafting of laws is that donors often sway elected officials, impacting their integrity.

This is due to the fact that the people drafting laws are also the ones trusted to ensure they're strong and watertight. This setup is ripe for a conflict of interests.

In software, we have testing as a part of the production process. Ensure code correctness and that it matches the spec prior to production deployment.

And as much as possible, automate the tests so that they're easier to run, more efficient, and thus more likely to be run.

The ideal QA / testing testing setup is one where the test writers and executors are different people to the coders. 

Coders want to ship on time and tend to be lazy about testing. 

Testers aren't emotionally invested in the code and can be more rigorous with their tests.

Applying this to laws, we would have a separating "tester house" for testing bills prior to them being passed as laws.

Lawmakers would stake money into a vault and submit their bill for testing. Testers would receive rewards from this pot for every loophole found.


Once enough time had elapsed, testing would be complete and the bill would be sent back for revisions. 

The process would then repeat until some criteria is met whereby the bill would is then deemed ready to be a law.

Example criteria could be:

* At least 5 rounds of testing have been completed.
* No loopholes found in the last round of testing.
* etc.

When submitting a bill for testing, lawmakers would specify the amount of money staked (and thus available as a payout) as well as the duration of time available for testing.

Testers would pick and choose the laws they wish to test according to what suits them best.

This creates a law-testing "market" of sorts whereby lawmakers need to offer enough and enough testing time to make it worth a tester's while to test their bill. The sooner they wish to get their bill passed, the better an offer they have to make to testers.

Any money remaining in the staking vault at the end of testing iterations would be returned to lawmakers as bonus income on top of their base salary. Note that testers would also be paid a base salary, and so any payout received by them would be bonus income.

These financial incentives result in two things:

* Lawmakers are incentivized to minimize the no. of loopholes in their laws.
* Testers are incentivized to find as many loopholes as possible

Testers can also be influenced and bribed. To try to mitigate this somewhat, the "tester house" membership would be open to anyone and everyone who wishes to be a tester, as long as they meet certain regulatory criteria. Testers would then compete against each other for jobs.

Automated testing is desirable. But it's not easy to express all laws as code. This is where I think LLMs and AI in general can play a role - in making it easier to come up with test cases and thus find loopholes in a given bill.

End of thread. Read my full post on this...

https://hiddentao.vc/blog/2024/04/16/fixing-leaky-laws

Fixing leaky laws with incentivized testing

 An update on @jigzaw_xyz - a fully on-chain NFT collection with a liquidity pool that I'm building...

✅ Artwork done 
✅ Contracts: Mint-swap pool
✅ Contracts: Lottery pot for most engaged fans 💰
👩🏽‍💻 Website - jigzaw.xyz
👩🏽‍💻 Marketing

Read on for details  ⬇️

For the art, it took a few iterations to get things to a satisfactory point. My requirements were:

* All images must be fully on-chain - this necessarily limits resolution and details to keep file size low.
* Images must be scalable - this necessitates SVGs

Initially I was simply treating each tile of the Jigzaw as an NFT, until I realized that people really like PFPs. So then I switched to creating PFPs and worked on choosing colour combinations which would allow them to still be used to form an image when combined together.

I drew everything in Figma in the form of layers and then built a custom studio app (a locally hosted React SPA) to test things out as well as build the Jigzaw puzzle from the images:


https://twitter.com/jigzaw_xyz/status/1770903501578592298

In terms of contracts, the @sudoswap-inspired mint-swap pool is code complete. Test coverage is around 97% at the moment, and some of the missing % is due to deficiencies in tooling. It's made me realize that we can do better:

https://twitter.com/hiddentao/status/1771648583114109083

https://twitter.com/hiddentao/status/1771648583114109083

I've looked into actually using Sudoswap instead of my own pool code but at present I'm not sure if the added code complexity and gas cost is worth the effort. Still investigating 🧐

Over the past week I've had discussions with friends about how to incentivize people to complete the puzzle and have come up with the idea of a "lottery"...

To summarize the lottery:

5% of each trade goes into a pot. Puzzle players will receive lottery tickets (also NFTs!) as they complete tasks. Once the puzzle is completed, a limited no. of winning tickets will be drawn from the pot. These tickets can then claim their share.

I can't wait to reveal the website - jigzaw.xyz - as it will go a long way towards explaining the nature of the puzzle, the lottery mechanism. And why the art work has to be the way it is. 

This is what I'm building this week, due to be ready by next week.

The bigger challenge up ahead is marketing. I'm totally new to this and am basically experimenting with different marketing methods. I think I need at least a few thousand eyeballs on the collection to make it reach escape velocity.

Current thoughts are to explore:

* Twitter posts / replies / mentions and DMs to key NFT accounts
* Set aside X no. of NFTs to gift to key people
* Subreddits / other forums
* Cross-posting on Farcaster / Lens

Any suggestions are welcome!

Update on JigzawNFT: an On-Chain NFT Collection

The concept of a globally unique digital id per human has profound implications for how we see ourselves and how we relate to each other. Family name, country of origin, ethnicity, all become less important. A flatter, more collaborative world....

A person's family name has traditionally been their unique identifier in a small society. Family names were initially often based on the vocation or other attributes of a particular group of people. And for a while, this made sense, when groups were small and/or non-migratory.

Over time, however, intermarriage, expansion, migration and vocational changes have meant that today a person's family name is just another piece in the full name that uniquely identifies them within a society. But even this remains insufficient as many have the same name.

Additional information is needed - address, relatives, face. At a national level a person is usually assigned a number - social security, driving license, passport, etc.

(Note: If a person loses their number/card they fallback to using other information to restore access.

Here's the thing - the numbers assigned to us are not globally unique.

Moreover, they're numbers assigned to us as opposed to having been chosen by us. So we don't have an attachment to them as we do our names.

The internet changes this dynamic.

The internet has given us the ability to have globally unique ids - web3 wallets, gamer handles, email addresses, social media ids. Moreover, we get to pick our ids and thus form an attachment to them. This is partly why many people reuse the same id across multiple apps.

A person may hold multiple such ids, each of which are unique, so they may have multiple public personas.

And a person's relations (mum, etc) don't utilise a similar-sounding id by default (unlike a family name) - so you can't tell who is related to who.

By the way, the idea of globally unique ids as THE means of organising humans in society is tacitly explored in books where the world is essentially one big MMORPG - think Daemon, Inc, Ready Player One.

Thanks to these ids being fully digital, it's easier to have social recovery mechanisms in place such that it would be possible for a person to recover access to their id without having to resort to non-unique forms of id (e.g name, address, etc).

(A note on biometrics such the face, fingerprints, etc: these are globally unique but they're also highly sensitive and non-succinct. A name is easier to both use and write, and it provides a level of desired pseudonymity)

Imagine world where a human being chose one or more globally unique ids for themselves and that's who they then were in life, as opposed to their current-style "name". What would the implications be?...

<> People would both see themselves and behave as globally unique individuals - Just think how different this is to how many people in the world see themselves today, i.e. belonging to a particular ethnic group, religious group, political group, country, etc.

<> People would be more willing to collaborate with other people from around the world due to this shift in perspective. This in turn will make them more open minded to different cultural backgrounds.

<> People all over the world have a chance to contribute to something - the playing field is more level. This in turn would lead to an enriched state of global culture, innovation and progress.

<> Having multiple ids means no longer thinking of oneself as having just one public reputation/history. This makes it psychologically easier for a person to explore different facets of themselves. This is almost enabling a spiritual inquiry into the nature of the self.

At the moment, I see MMO games and open source software communities demonstrating the above characteristics. And since thing such as crypto were born out of the open source movement they too inherit these characteristics.

This leads to an interesting axiom...

Any movement that grows out of the internet and in particular, gaming and/or open source, is likely to inherit the above characteristics at a philosophical and cultural level.

The Evolution of Personal Identification

Building fully on-chain games throws up a no. of issues, all of which arise from not having a typical centralized server-side backend:

- 💿 Where to store assets.
- 🔐 Where to store per-player private data.
- ⏰ How to run cron tasks.
- 🚫 How to prevent cheating.

🧵...

[💿 Where to store assets]

Storing assets on-chain would mean storing assets in smart contracts. The key constraint to note is that storing data cost a lot of gas (see SSTORE in EVM). Thus, it's a a good idea to minimize both the amount of data + the no. of storage writes.

 Alternatively, one could use progressively-generated assets with seed values stored on-chain. The trade-off would be increased game loading time. And as game assets get more complex, progressive generation might not suffice. Thus, we still need to actually store data.

Off-chain storage is a viable option. Store data off-chain and link to it on-chain (e.g. via an IPFS cid). But, if storing on an off-chain backend then anyone should be able to spin up a node that replicates the stored data. Examples: @IPFS and @farcaster_xyz.

[🔐 Where to store per-player private data]

Data that only the player should be able to see can be stored on-chain as long as it's encrypted with a key only known by the player - we could generate a symmetric key derived from a digital signature based on the player's wallet.

Note that - as with assets - the amount of data being stored on-chain should be minimal. And note that storing the player's private data off-chain has the same requirements, i.e. the data must be encrypted with a key only known to the player.

Where this data can be stored depends on the game type. For instance, if the game is real-time then it can be stored on the player's device itself. But if the game is turn based and supports "idle" play (e.g Risk/Warzone) then this data would need to be stored externally.

And likewise for assets, any external storage of player private data should ideally be replicated and decentralized in order to minimize centralization risk. The strictness of this requirement varies based on the type of game.

Per-player data may need to be revealable to other players (e.g. one's poker hand) as part of the game. For real-time games this data can be stored on their device itself since the player is logged on during the game. But what if the game is turn-based and asynchronous?

E.g in a game such as Risk/Warzone, players place their moves and then must wait for other players to do the same. Once all players have placed their moves the system must process the moves and advance the game board to the next round.

Such a game requires players to be able to store their move data privately until its time to reveal it. In addition to this, there needs to be a way to run an automated task at a game system level, either according to a schedule or trigger. Which leads us to...


[⏰ How to run cron tasks]

Smart contracts are transaction-triggered and don't support automated tasks out of the box. For tasks triggered by certain player actions, the task could be bundled into the player's action as long as it's not expensive.

Taking the previous example of Risk, once all players have made their moves the system must process them. So, we could implement it such that the last player to set their moves also runs the processing logic. Instead, if the task must be on a schedule then we need servers.

Mirroring how we do for game assets, any such processing servers should be easy for anyone to setup and connect to the wider network of such servers. This minimizes centralization risk.

[🚫 How to prevent cheating]

When it comes to off-chain logic, whether it's executed by a player or processing server, it is crucial for the contract to be able to verify correct and honest execution of game logic. This is where zk proofs - e.g @RiscZero - come into play.

However, generating proofs doesn't align well with a real-time game running at 60fps. Therefore, the type of game being developed significantly influences how zero-knowledge (zk) proofs can be utilized, and even determines if they can be used at all.

Overall, if we zoom out on the above criteria it's clear that we need a network of servers that can handle assets, per-player private data and zk-verifiable compute. It's obvious that the blockchain itself should handle these since it is an incentivized network of servers!

Handling this at the chain layer would also allow for the best UX and DX. There are a few gaming-focused chains contending here but none which do all of the above. I think there is a need (and opportunity) to build out the needed infrastructure for existing high-TVL chains.

Challenges of Building On-Chain Games

Gemforge v2 is out, with a number of new features!

· Reset deployments - reset existing Diamonds by removing and re-adding all selectors
· Targets vs Networks - deploy multiple instances to the same chain
· Custom initialization - pass custom args to the init method.

Reset deployments.

Sometimes you're not sure what facets and selectors are deployed and you may wish to simply reset the Diamond to a pristine state with the latest facet selectors.

You can now do this with the --reset CLI argument.

Targets vs Networks

Previously, you could only deploy one instance of your Diamond to a given network/chain. Now you can deploy multiple instances to a given network/chain, each using a different wallet and different initialization parameters.

Custom initialization

You can now pass arguments to the InitDiamond.init() method (and even change the contract and method name). Better yet, arguments are configured per-target, meaning you can customize each deployment!

The Gemforge docs have also been enhanced, with additional best practices on modifying the storage structs, modifying facets, sharing code, etc.

And.....there are now integration tests covering all the essential functionality of Gemforge, so you know it's rock solid!

See the latest docs at https://gemforge.xyz and grab the code at https://github.com/gemstation/gemforge

Gemforge v2: Reset Deployments, Targets vs Networks

Blockchains are on the verge of commoditization. As a result, value accrual will shift higher up the stack, rather than being concentrated at the chain level.

This parallels the evolution of the internet, where value eventually shifted from internet access to websites/apps.

At present, there is still intense L1 competition, and inter-chain communication (via e.g. CCIP) is still in the early stages. Once these have progressed, this level of the stack will be less exciting to look at.

Not only that, but more capital will shift to the higher levels

What are the higher levels? Protocols and dapps.

The protocols and apps that establish themselves now have a head start in potentially dominating their respective categories in the future. This assumes they evolve to take advantage of improvements in the foundational layers.

Evolution could entails several actions:

- Porting contracts to a more efficient arc (e.g., Rust) to lower gas costs.
- Becoming omni-chain.
- Enhancing user onboarding - account abstraction, social login and recovery, etc.
- Utilising crypto math advancements, e.g zk.
- etc

Protocols and dapps either evolve and thrive or perish, replaced by superior alternatives.

The same axiom applies to web3 games due to their unique nature.

As an investor, I remain highly interested in the L1/L2 layers.

As a developer, I am shifting focus towards the dapp layer. This includes exploring tooling and on-chain infra that will be valuable and envisioning the possibilities for upcoming dapps in the near future.

The Future of Blockchains: Shifting Value and Capital

There is an opportunity for L2s to bake a naming system into the core of their chains and eliminate hex wallet addresses altogether.

This all wallet addresses would be human-readable, resulting in especially good UX for when onboarding crypto noobs...

Of course, we have named wallets already - ENS.

And yet there are still a lot of hex public key addresses floating around the web3 space.

One reason is that obtaining an ENS name requires you to go to ENS and registering for one (and then remembering to renew it, etc).

Dapps which create wallets for users (think EIP-4337) can and should create human-readable ENS subdomain-ed accounts for those wallets.

But when the user goes out of the dapp to explore the space they are still going to encounter hex addresses.

This is where L2s come in...

Since we can configure at the chain level, we can build naming into the chain itself.

The chain could have an ENS domain and then register subdomains against this, for when a user first onboards or bridges over.

Of course, it could also choose to do its own naming sytem.

Users who directly onboard onto the chain and never bridge out would then never see hex addresses.

The closest thing to this right now is NEAR's chain, which only has human-readable wallet names, like ENS.

I found that to be great and commend them on that design decision.


Eliminating Hex Wallet Addresses: Towards a Human-Readable Naming System

Having tried out @friendtech I think it's most useful as a means for 2 types of interactions;

* Twitter celeb ↔️ follower
* Expert ↔️ knowledge seeker

Aside from these two use cases, it's just a speculative game and won't grow much beyond it's present state..

What makes @friendtech great is two features:

★ Holding a key enables you to chat with the account whose key it is.
★ As an account holder, you earn fees when people trade your keys.

Thus, both types of stakeholders are incentivized to use it.

But the value of the platform is primarly driven by demand for acquiring account keys, which either comes from wanting to chat with a key's account or from speculation around key prices.

The former is the sustainable path and should be what the platform tries to optimize for.

This then comes down to why I would want to speak to a particular account holder, and thus buy their key.

I either want to gain some knowledge or simply have the chance to chat with them.

And there has to be reason I would do this beyond simply sending a Twitter DM.

The only reason I can think of is that my DMs won't get seen if I message them via Twitter.

So either they have a massive no. of incoming DMs or they've turned them off.

This narrows down the utility of @friendtech to a small proportion of the Twitter user base.

Unless you're one of the few experts in a niche field and use Twitter as a means of disseminating information, or you're a Twitter celebrity, you're probably not going to make much money or gain much use out of @friendtech

Having said that, I would like to see something like this for ALL social media followings, as I think it's quite a cool way of monetizing access.

/eot

FriendTech: The Power of Interactions

I don't think a mass-market, decentralized, uncensorable social network is possible.

The main reason for this?

To enable mass onboarding, easier UX (i.e., centralized gateways) will be needed, and these will then become the choke points.

🧶...

Decentralization and censorship resistance go hand in hand.

Users who are technical enough will be able to get on. But for less tech-savvy and/or less patient users, these solutions have too much UX friction.

We've seen this time and again with PGP mail, crypto wallets, etc.

This is due to the following trifecta:

(1) High decentralization (self-custody, ownership)
(2) High censorship-resistance
(3) High usability (low UX friction)

Apps can typically only choose upto 2 out of the above 3 to optimize for. Most of the time there is a trade-off.

Some examples...

Crypto hardware wallets - (1) and (2)
PGP email - (1) and (2)
Standard email - (1) and (3)
Signal messenger - (2) and (3)
Twitter/X - (2) and (3)

The exact amount of each factor varies with every app, but it's very difficult to achieve (1), (2) and (3).

Is it possible to ever optimize for all 3 factors?

Yes, but only once one of the factors becomes irrelevant due to socio-cultural shifts. At which point the optimization challenge moves up the stack.

For example...

If in the future the vast majority of people have crypto hardware wallets and are regularly using them with ease then factor (3) wouldn't be relevant anymore.

At this point we would then be able to design products and protocols which assume the existence of a hardware wallet.

An analogy can be found with smartphones. Now that they're ubiquitous it's easy enough for the vast majority of the population to learn to use them, if they don't already know. And nearly all of them have a myriad of ways of talking to each other, with encryption.

Things like this become viable:

https://www.bbc.co.uk/news/technology-49565587

Going back to the idea of a mass-market, decentralized, uncensorable social network, to hit all 3 factors, we would need factor (1) to be taken care of first, as (2) naturally follows from it. This would then allow us to focus on making (3) as great as possible.

As it currently stands, we can build a decentralized, censorship resistance base network which then has easy-onboarding apps that help the less tech savvy folk get on.

But the easy-onboarding apps will be custodial and thus able to censor (or they can be compelled to).

Thinking about it, this is exactly the crypto space we have today.

Use hardware wallets and take on responsibility for one's keys - (1) and (2).

...or...

Use Coinbase wallet and not worry about losing keys - (2) and (3).

As soon as we're able to optimize for all 3 factors with the state-of-the-art, that tech is longer the state-of-the-art and the next wave comes to replace it.

The good news is that the baseline tech is constantly improving :)

/eot

The Challenges of Decentralized Social Networks

.@zetablockchain is attempting to link all blockchains together within a single EVM-compatible L1.

But how? By having built-in support for cross-chain txs.

I was curious, so took a quick look at the cross-chain docs (https://www.zetachain.com/docs/architecture/modules/crosschain/overview/) and this is the rough outline..

Zeta nodes run observer clients, which monitor other supported blockchains.

When they observe an inbound transaction to Zeta, nodes vote on its validity. If found to be valid, the final voter pays the gas cost of executing the transaction on Zeta.

Inbound transaction can not only deposit tokens from other chains (which become ZRC-20), but also make contract calls to Zeta contracts.

For outbound transactions, a threshold signing ceremony is used to reach consensus in sending a signed transaction to another chain.

Interestingly, the outbound Zeta transaction doesn't itself finalize until the transaction on the other chain has finished executing, making the whole thing atomic.

Presumably, for transactions heading to BTC this means the Zeta tx would take 10 minutes to finalize?

Thus, the asset bridging in Zeta functions similarly to existing bridges, except that the base chain itself operates the bridge. The security of the bridge is thus dependent on the security of the consensus backing Zeta and that of the chains being bridged to.

This approach is still lacking compared to what a trust-minimed bridge between two zk chains would offer (i.e. "trust math, not validators").

However, I like Zeta's approach in that it's better than having a fragmented ecosystem of private bridges, each having a hack risk.

On another note, using threshold signing schemes to have a group of nodes operate a wallet for another chain seems to be the standard for doing this sort of thing. @Stacks is doing the same for their upcoming sBTC peg.