# Why do we need blockchain names? Engines such as Dojo are making it easier to spin up composables and persistent games running entirely on the blockchain. The architecture relies on having a world contract listing down all the systems, components and entities in that particular world, making it easy to follow changes and providing a single point of entry to the world. ![](https://hackmd.io/_uploads/rJKa4sUW6.png) Let's say we built a game built with Dojo and deployed it on the blockchain. The world contract of this game will have its own dedicated address and that's all well and good. But how do you find this world? You can find it by googling the name of the game, the team, and find one client that is serving this game. But how do you know for *sure* the world contract address is the real one? When deploying a world contract you give it a name, but there could be multiple world contracts with the same name, making it difficult to find which is the legitimate one. ![](https://hackmd.io/_uploads/rJ6fUiUZp.png) This is not an uncommon problem in blockchain. When sending funds to a friend you need to be extra careful you're using the correct address: that you haven't made any mistake and that it was indeed your friend who sent you their address and not someone impersonating them. These issues can be mitigated by using a naming system, like the [Ethereum Naming System](https://ens.domains/). ENS allows users to register a name, similarly to a domain name, that will resolve to their address. Rather than sending funds to `0xc0ffee254729296a45a3885639AC7E10F9d54979`, you send the funds to `myfirstname.eth` through compatible wallets and the resolver will take care of using the correct address. ![](https://hackmd.io/_uploads/Skk3KjUZ6.png) Users will pay a fee to register their name for a period of time. On ENS the price depends on the duration of the registration, and how many letters the name name has. What if we used a similar system to register and name worlds contracts? # The world registry Imagine a world registry where worlds creators would register their world contract address and give it a name. This would have several benefits: * It would be easier to know what's the legitimate world contract of a given world and make transactions easier to audit: you know you've interacted with briq.world rather than anything else. * It would allow anyone to easily query the list of available world and make (https://book.starknet.io/chapter_3/account_abstraction.html)) * Help game aggregators like the one built by [Cartridge](https://cartridge.gg/) discover and list worlds. We could even imagine different registries for different usage: all the games in the RPG registry would need to use the "RPG-compliant" systems, the Dojo official registry would require games to be built using Dojo. Registering a world to a given registry would require passing an onchain test attesting the world contract and the systems/components/entities comply with a set of rules. ![](https://hackmd.io/_uploads/BJ30vJvba.png) # Some more ideas * IPFS resolver to host the official version of the client: similarly to ENS which allows hosting websites such as vitalik.eth on IPFS and resolve the URL to this website, the "official" client of a game could be hosted and resolved through the world registry. * Subdomains for games within worlds: the [Realms](https://realms.world/) ecosystem has built two games, [Loot Survivors](https://survivor.realms.world/) and [Eternum](https://realms.world/games/realms-adventurers). Both of these games exist within the Realms world. They could therefore be registered as subdomains or subworlds (survivors.realms.world, eternum.realms.world), similarly to how one can generate subdomains from their ENS. Future games could even apply to be added as subworlds to the registry and pay a fee to the owner address of the main world to be registered as an official subworld. # Problems * [Domain squatting](https://en.wikipedia.org/wiki/Cybersquatting): what if someone registers realms.world before the legitimate team and uses it to scam people? It's a common problem for naming systems which can be mitigated in certain ways through a sort of tax (see [this](https://vitalik.eth.limo/general/2022/09/09/ens.html), [this](https://mirror.xyz/nick.eth/EAH91vsu24WlvIqs3os-ISEpgnqIic0Y3z_asUVtGy4) and [this](https://vitalik.eth.limo/general/2022/09/09/ens.html)). In the context of autonomous worlds the tax paid could be indexed on the gas usage of the world, as an indicator of how much usage the game has and therefore how valuable its name is. * Fair pricing of the domains: pricing domain names is notoriously hard, and there are countless discussions on the topic on the ENS forum. ENS has chosen to base their pricing on the number of letters in the name and how long the name will be held on. For worlds I don't think pricing based on the number of letter makes much sense. Price indexing based on the gas usage of a world would be a way to map to popularity.
Last changed by  
 
s0lness
143

Read more

Provable gods and autonomous worlds

Two trends are shaking up the gaming worlds: artificial intelligence and autonomous world. LLMs offer new ways to escape the content creation rat race by reducing the marginal cost of content creation (see ChatGPT playing Ultima Online). By leveraging the decentralization and trustlessness properties of blockchain, games can also create new affordances and live without any single centralized entity. Think of an evergreen game of "r/place" running entirely on the blockchain, that no one can turn off. Zero-knowledge proofs and validity proofs could be a third affordance, providing game builders a way to offload computation to end-clients and trust the output, obfuscate information, run trustless P2P multiplayer systems with local consensus rather than executing the game on a centralized server. We had a fun thought experiment during the Bitkraft summit that mixes all three technologies. Buckle up. Picture an autonomous world called Gaia. The game is a simulation of a planet which physics systems are running on the blockchain directly. The game is made of a few systems, such as weather, population, etc. The system ticks forward every block and different parameters of the planet evolve: temperature, number of humans, number of trees, etc. How do we make sure Gaia generates drama or sufficient "fun" for people to care about a planet simulation? (I'd argue not much, since people are already watching marbles racing but that's another topic). Let's introduce a game mechanic where players are able to decide what happens to the planet, similarly to Twitch Plays Pokémon. You'd have 100s of players competing to get an outcome they believe is interesting. Crashing an asteroid in the planet, raising the temperature by a few degrees and seeing what happens. What if we asked an AI to choose the outcome of certain functions? Let's call these AI gods. The world contract would reference a god_list that can be called upon by players. Let's say we have two competing gods. One of them is an orderly god trying to take care of the planet, and a chaotic god trying to set it on fire. Players can use the pray(god_id, amount) system to tip the scales in favour of their god to win the next theological event round.

10/16/2023
No-coder in a coding world

Thoughts on being technologically-literate but technically mute in the dev-centric Web3 ecosystem. I'm not a developer. The most I've contributed to briq's codebase is my lackluster JS code during the ETH Lisbon 2021 hackathon, with my cofounder Lancelot correcting every other line I wrote while writing his first lines of Cairo. Back at Ledger I wrote some neat Python scripts to automate the boring stuff and can build virtually anything on Excel. Blockchain-wise I've never written a line of Solidity, have never deployed a smart contract. But I'm a black belt in Etherscan-fu and understand what CPFP means. I consider myself mute but technically literate. Blockchain space has a biais towards technical discussion: you must use the fancy words and talk about the latest word salad to be in. I'm no stranger to that. Maybe 5% of crypto twitter has actually written a line of Solidity, but we're all pretending to be developers and act as if everyone were a developer. It's strange to be a generalist, somewhat techy person, when the narrative baseline in the ecosystem is to be a developer. After all, the Bitcoin whitepaper was published in a cypherpunk mailing list, don't all "Cypherpunks write code"?

4/17/2023
Random thoughts on Account Abstraction

Hey folks, it's Sylve aka s0lness building briq on StarkNet. We're all hyped up at the prospect of higher programmability for our wallets, I thought I'd jump in and share some of what I've seen recently. The examples provided below revolve around StarkNet but could be applicable to other network supporting account abstraction. Account Abstraction, a primer On Ethereum L1 you have two entities: Externally Owned accounts (EOA) and smart contracts. EOAs are addresses on the blockchain controlled by a private key. You generate them by creating a private key and deriving a blockchain address from it. You now control the key that can sign transactions from said address. But the key is the account: you can't authorize another key to sign for a given address and you can't code custom logic on top it. Governance and spending logic have to be implemented outside of the blockchain. A smart contract is basically code held at a certain address on the blockchain. Some smart contracts are built to behave like wallets and are aptly called "smart wallets". You can be very creative with smart wallets because you don't have a unique signing key: for example, multisignature contracts like Gnosis safes allow you to define a spending quorum, ("you need signature from 2 out of 3 authorized keys to validate transactions"), and add other governance features on top of it ("this address can only spend 50 USDC per day").

1/5/2023
Read more from s0lness
Published on HackMD