Future of proof-of-on-chain-work

Now that proof-of-on-chain-work is a thing, I think it’s time to think about the broader implications this could have and how we can standardise and leverage the unique properties of this “new” and fair(er) approach of distributing tokens.

In the “old” meta, projects trying to conduct a “fair” launch did so by locking the entire supply in a pool with some initial liquidity provided and then burning the LP tokens, making it impossible to rug pull. This is a good start, but it doesn’t solve the problem of insiders and sophisticated users acquiring a majority of the coins.
As soon as the pool has been created, large buys can be placed to buy up large amounts of the coin, sometimes using sniper bots. These are bots constantly scanning the blockchain for new pools, trying to get in as early as possible to extract as much value as possible. Everything revolves around getting in early to extract value from everyone coming in after you.

With the new proof-of-on-chain-work meta established by bob.fun, the absurdity of getting in early is softened by establishing a well known mechanism, Bitcoin’s Proof-of-Work. By using a similar approach, we ensure that no single player is able to immediately secure a big chunk of the supply, as new tokens are distributed over the courses of time. But this meta does not only benefit investors, but the entire ecosystem by burning ICP to create cycles which are then burned again to (more or less) solve cryptographic puzzles. This boosts the cycle burn rate (already at an ATH) and – as of today – made the ICP deflationary. I don’t need to explain the excitement of having your own Tamagotchi-like miner that you nurture with cycles and send to the mines to do hard work while you drink coffee :slight_smile:

We now have the chance to standardise and promote this new distribution mechanism outside of our own ecosystem. Unfortunately, the bob.fun repository has not been open-sourced until now, so for some architectural proposals I use a setup I was working on in the past. It uses different lingo but I think fundamentally it describes a very similar system. It would be great to have the following things:

Launchpad

A launchpad were projects can launch new tokens on the ICP with the aforementioned distribution mechanism. That is, after specifying settings such as the

  • maximum supply,
  • the halving schedule,
  • how frequently the difficulty will be adjusted,
  • the block time
  • target chain (see “Chain Fusion Minters”)
  • general token settings such as logo, ticker, name, transaction costs

This would spawn two canisters, the minter canister and an ICRC-2 Ledger. Instead of creating a new mother node for every new token, we would keep a single, global mother node that is responsible for spawning new miners, upgrading them and keeping a registry of them. This opens up the possibility for participants to “bring your own miner”, that is decide what token they want to mine, similar to how miners in the real world can decide what network they would like to commit their hash power to.

While the mother node is the sole controller on the protocol level, the user currently has some control on the canister level, such as changing the hash rate and the “owner” (that is beneficiary for tokens in case a block has been mined). All we would need to do to enable the above from a miner canister perspective is to give users the ability to set a different minter canister id for their miners. They would fetch all necessary information needed to mine from this canister instead from the mother node, in the current architecture. Upon successfully validating a PoW from a Miner, the Minter would check if the submitter is registered with the Mother Node (this could also be swapped, depending on what is cheaper). Ideally we have some sort of caching in place in the Minter so that we do not need to check if a miner is registered for every PoW submitted. We would also need to investigate how scalable such a single mother node for all tokens is.

Mining Pools

Something that has been discussed multiple times already and even implemented by @skilesare (see here) are decentralised mining pools. Instead of participating in the big lottery as a solo miner, users can contribute hash power to a mining pool. For this, they spawn a miner canister and then set the owner to the pool canister. This flow can be facilitated through the mining pools frontend. You can either spawn a new miner or bring your own miner. The mining pool keeps track who contributed which miners to it’s pool and allows users to remove their miners from the pool to either solo mine or contribute them to a different pool. Of course the pool provider takes a share of the block rewards for his services :wink:

Chain Fusion Minters

Why restrict minting tokens to the ICP? With Chain Key Signatures we can “easily” configure a minter to issue tokens on other chains. This could work two ways.

Either by creating an ERC20 contract on Ethereum for example that has the Minter Canister set as the token minting authority. Now whenever a miner submits a valid PoW the minter creates, signs and submits a transaction that would mint the corresponding tokens on the ERC-20 contract to the beneficiary. In this case it’s not entirely clear which address on the Ethereum network would receive the tokens. It would probably help to allow miner owners to specify yet another setting, and that is an explicit beneficiary. We would need to think about how to structure this in the case the minters are able to target many different chains, and that is many different address formats. Maybe it’s sufficient to provide a simple string as the beneficiary and it’s up to the frontend/user to make sure it is valid for the target network they are mining for. With this approach, the minter canister needs to hold a certain balance of the target networks token to be able to subsidise the transaction fees when a new block has been mined, which could be rather expensive in the long run.

Another approach would be to create an ERC20 contract with an extended interface to verify ECDSA or EdDSA signatures against the public key of the minter canister. We then let the minter sign a coupon, that is a Chain Key signed object that contains information about how many tokens should be minted to which address. This coupon is cached by either the miner or the minter and can be retrieved by the owner of the miner that mined the block. The owner of the miner would take this signed object and provide it to smart contract on the target chain by submitting a transaction, e.g. calling a claimTokens endpoint providing the coupon as call data. The ERC20 contract would then verify the signature on the coupon against the public key of the Minter canister it has stored, and if valid mint the amount of tokens to the beneficiary accordingly.

Especially for this particular use-case – that was brought up by @domwoe in a conversation – I can see how the ICP becomes very attractive as an infrastructure layer for other ecosystems and we’re able to onboard fresh people from other ecosystems to the ICP.

What now?

We should come together as a community and try and standardise the necessary infrastructure needed to enable this and many other use cases and ideas that haven’t been thought of or articulated yet. Please use this topic to share your own ideas, provide feedback and engage!

33 Likes

PS: wen public repo and blackhole monitoring for miners for bob.fun :eyes:

12 Likes

This is a good proposition, and it is expected that future meme releases can be transparent and fair

4 Likes

Good idea, this grap our attention,maybe we can consider building something like this on BTC or ckbtc?

3 Likes

I think the idea of ‘proof-of-on-chain-work’ on the Internet Computer is fantastic! Bitcoin has shown that Proof-of-Work can be highly effective despite the costs. So why shouldn’t it work with burning cycles on ICP? This model even offers benefits: it uses a more efficient and sustainable resource (cycles) while driving deflationary pressure on ICP. Excited to see where this new approach leads!

6 Likes

Could we take this one step further. ICP is advertised as Proof of Useful Work. Couldnt the miners calculate some scientific work or provide some other value instead of just consuming electricity/ onchain compute.

Another idea is that imo Blockchain On Blockchain refers to running node validators (and any complementary tech) onchain. ICP could decentralize and unlimit Proof of Stake blockchains. Imagine Cardano, or XRP, or Tron etc, use ICP hardware (sovereign compute/ cloud) and focus on software, community, value.

7 Likes

You could build fair launches of Bitcoin metaprotocol tokens like Runes or BRC-20 on top of the ideas @cryptoschindler described.

6 Likes

Thanks for the feedback! Could also really benefit liquidity on BTC i think. :face_with_monocle:

2 Likes

The concept of burning cycles as part of proof-of-work (PoW) mining for token distribution is interesting but not necessarily fundamental. Cycles are an abstraction, and this mechanism could be substituted for anything that represents resource consumption.

For instance, using a blackholed canister with trusted random numbers, we could eliminate the burning entirely while still maintaining fairness in token distribution. The token issuer would retain the ICP for funding, which could be allocated for future developments or other activities.

This raises two questions:

  1. If we can abstract it and the burning cycle is irrelevant, the we’re back to what people can pay and how early they are. How is this POW different than an SNS that has no team allocation and burns any ICP it gets in the swap? Is it that it runs over a long period of time? Is it that the earlier you are the more you get so it builds hype? In some domains(including legal ones) that is called something that starts with p, ends with an i, and has a z in it. Theoretically you could have your SNS run for a long time and you could mint tokens to users who get in early along a bonding curve. A tweak here and there and you end up with something similar. I’m not saying there isn’t something to this PoW thing…I just haven’t identified it yet.

  2. What is it about burning resources that appeals so strongly to the community? It seems there is a collective preference to burn tokens rather than give them to developers. What does this say about how we value resource use and scarcity in the ecosystem? I mean, are we broken? What is it about our community that would rather see resources burned than given to someone who has created value? Maybe too philosophical a question for this forum, but it is on my mind.

Regarding ChainFusion integration, I think the second approach in your architecture is preferable. The first model introduces unnecessary complexity by combining PoW mining with pushing to other chains. Keeping PoW mining and cross-chain transfers as separate, modular components would make the system more maintainable. This idea closely resembles your second diagram but with a refinement: instead of issuing a coupon to users, you could mint ICRC1 tokens directly on an ICRC1 canister, with a burn function that triggers a mint operation on a foreign chain using tecdsa. This would reduce gas costs and allow users to bundle token transfers, which increases efficiency for large-scale transfers.

13 Likes

Can’t agree more with skilesare

1 Like

100% agree @skilesare . We’ll see what happens with BOB but crypto history taught us the fate of most ‘BTC competitors.’

If BOB proves unsustainable (and it will imo), its Gamification is already proven a great success.

For fair launches (not chain-fusion stuff), might I propose we just simulate the mining process without burning $10k+/day. It’s very simple, just use an icrc1 token with a substantial fee and mint mining rewards to recent transactors. All collected ICP can return to stakers instead of burns (or the team if you choose to ruin this idea). If you flatten the BTC reward blocks by several orders of magnitude, early whales/fair-launch participants have no unfair advantage.

I’ve already tested this method locally with 60+ Billion block rewards. Bob.fun made me think about releasing in a minigame, but I’d rather launch with the main product. If anyone is interested it’s open-source: (concept/mechanics, block-reward-canister, mining-mechanism-canister).

6 Likes

“The concept of burning cycles as part of proof-of-work (PoW) mining for token distribution is interesting but not necessarily fundamental.”
Not needed yes, but it will add value to token that is mined. No need hundreds of minable tokens that are basically like airdropped for free. Than you coud just make platform where you stake max 100 ICP per person and get free tokens, that dont really add value.

1 Like

proof-of-on-chain-work, this shoud work very well with games. Top up, play game, at same time it burns low amount ICP and mines for you, than you can use mined token ingame, or sell on market.
Or if want so get tokens to everyone, just make app that pulls all ICP addresses and every day it sends tokens to them, but as you know free tokens will hold no value.

2 Likes

“What is it about burning resources that appeals so strongly to the community? It seems there is a collective preference to burn tokens rather than give them to developers.”

Isn’t this just economics?
Assuming no other use case for a new token.
We can’t create a new token of X value out of thin air.
If I buy 1000 of a new token off a dev with 1000 of an old token, how do we say the new token has 1000 of the old token in value? The old token still exists. Instead of 1000 tokens we have 2000 tokens just in a mix of new and old.
If I burn 1000 of my old token to receive 1000 of the new, then the new token has taken on the value of the 1000 I burnt.

3 Likes

How about powering AI queries? :thinking:

3 Likes

Burning cycles to mint tokens gives an inherent value to said tokens (the cost of the cycles used to mint)
Burning cycles also eats up ICP, which if enough of these PoOCW tokens were made and mined would likely cause the ICP token to become deflationary quite quickly. With just BOB the cycle burnrate skyrocketed to a massive all time high.
I think a launchpad, or at least a FOSS PoOCW token standard, would be great for the ecosystem. Its clear how much hype BOB made and it would be a type of memecoin completely unique to the ICP network, which could draw in users from other smart contract chains who like slinging memecoins.

Proof-of-useful-on-chain-work (PoUOCW? These acronyms are getting big!) would be even better though.

3 Likes

But your suggestion doesnt take ICP out of the market. It put it back in the hands of devs who are going to sell it and put sell presure on ICP the asset. The point of a pow on chain is two things: fair distribution and sov meme. You can create coins that have value out of the gate because their creation involved the use of non resusable resources. Its simple and easy to understand. This is why pow meme coin like kaspa is as valuable ICP. Remember there is an investment aspect to ICP. Its not just tech.

5 Likes

Plus it’s easy to explain to somebody why this thing has value and why they should buy it. It is fair. It doesnt feels like its created out of thin air even if it is.

Agreed. Burning ICP is the utility of non-useful PoOCW coins. And its a good utility.

I feel like the developer community would want to mostly focus on useful work for mining, since it provides the utility for investors (deflation) as well as utility for the network (useful computational work).
A token that does useful computational work to mine that has fairer payouts/emissions than BOB and is fully open source would probably do very well.

Burning tokens is a bit like giving more value to everyone who owns a token (developers included - but not preferentially).

I’m not saying there isn’t something to this PoW thing…I just haven’t identified it yet.

I think it comes down to the fact that it represents real scarcity, in the sense that work needs to be done (it cannot be faked). Simulating this, to fake the work, makes the scarcity less real (for lack of a better word). I do see where you’re coming from though.

5 Likes