I am noticing that there’s a sizable amount of prospective builders out there who are afraid of building a parachain on Polkadot, due to the fact that they may lose their parachain slot after a certain period of time.
This fear is unfounded, as we know that a chain that is popular and is needed by a company would have no problems gathering the relay chain tokens required to auction for another slot. And if they cannot do so, then it is proof that their chain did not gain enough traction, and should then continue on using the pay-per-block model of a parathread.
Such a phenomenon makes me realize that there seems to be not enough venues in which we tell the story behind each and every game theoretic design decisions that went into every FRAME pallet. @shawntabrizi has been doing an excellent job in spreading the knowledge in his presentations, but it would seem that we need to have a more concerted effort in publishing the narrative. The first go-to location would obviously be the developer docs, but I feel that it isn’t quite enough. Thoughts?
My personal experience and observations are pretty much opposite. Due to too generous first crowdloans, which raised very high amounts of relay chain tokens, high competition in first rounds and unclear complexity of starting crowdloan and becoming parachain, devs start to think that:
it’s too expensive, yes you are reading it right
some parachains raised too much money in crowdloans (even crypto professionals are not aware of true nature of crowdloans which are not fundraising event but safe loan)
those big amounts of contributed assets didn’t help teams in any way
whole process is too nuanced and too much of hassle instead of being solochain or smart contract based protocol on smart contract chain
tldr; devs are afraid of idea even start as parachain. Imho we should focus and make bigger effort on education or debunking wrong narratives around crowdloans & parachains and highlight their strengths and unique value propositions. Then we can make them calm, that useful code & products will survive and will be appreciated in our ecosystem.
I want to steer the conversation away from this one particular problem but focus more on the general problem, and that is how exactly we can put out the proper narrative around FRAME.
Here’s another example that I recently came across: one of the proposers on Polkadot was asking why they can’t freely cancel a treasury proposal that they’ve submitted – there is no extrinsic that they can call to do so. Thinking along the principles of game theory would also hint towards the direction of the deposit: if there was indeed a quick cancellation process, then all treasury proposal’s deposit would be rendered useless, as it then could not effectively prevent spam.
It would then seem to me that the public in general does not have a strong grasp behind the principles of the game theory behind every design decision we make. I’m not sure how exactly we can address this problem as it is quite abstract and looks as if it’s linking various disparate components of the blockchain together. Questions like “why is there a maximum nominator limit?” and “what’s the purpose of the existential deposit?” are examples of how different these questions look like at first glance, but both have almost the same underlying principle or design decision behind them.
Personally, I loved the game theoretic exercises we did at the Academy. Do we have something similar for wider audience? I think they teach the underlying mechanics a lot better than a document could ever do.
Here’s another example that I recently came across: one of the proposers on Polkadot was asking why they can’t freely cancel a treasury proposal that they’ve submitted – there is no extrinsic that they can call to do so. Thinking along the principles of game theory would also hint towards the direction of the deposit: if there was indeed a quick cancellation process, then all treasury proposal’s deposit would be rendered useless, as it then could not effectively prevent spam.
As someone new to FRAME and often exploring new pallets, sometimes I’ll be reading a call or some logic and understand what it does, but not why exactly it was designed that way. The documentation often helps with the what, but seldom with the why or explaining the big picture of the pallet.
So primarily I think this is a pallet documentation issue, rather than a game theory education issue. Pallet docs probably should be expanded to explain the rationale behind the chosen design decisions (including but not limited to game theoretical decisions), which are often non-obvious.
When a developer asks a sensible question that is not included in the docs, it would be great if the FRAME dev community had a habit of adding the answer to the docs so that they are always improving.
Echoing Liam here - having a place to learn about a pallet’s design decisions, rationale, and reasoning behind it is very useful for several reasons:
Learn the place of game theoretical concepts in the Polkadot paraverse
Offer tangible implementations of those concepts in pallets and real world interactions
Offer a place of reference for those exploring FRAME to properly understand good pallet building practices in both the theoretical and technical areas of design.
This could be done either in the Polkadot Wiki, or Substrate Docs (latter is more befitting IMO).
A game-theory-from-scratch would be quite a cool way to get the message across
This could be done either in the Polkadot Wiki, or Substrate Docs (latter is more befitting IMO).
I’d suggest starting with just improving the existing outer doc comments, which are generated into these doc pages.
It doesn’t sound right to me that there’re two parallel (and different) sets of docs at the https://paritytech.github.io/ docs and docs.substrate.io. Ideally I think docs.substrate.io would have pages that’re automatically kept up to date with changes from the code comments, instead of needing to duplicate the docs once in code once on the docs site.
I agree with this - I was going to do something similar for the Wiki. I feel doc overlaps could be avoided through a mechanism in which either:
Pallet documentation is directly incorporated where relevant, so those docs are exposed on docs.substrate.io or the Wiki parsed directly from pallet code/README.
Have some mechanism to indicate whenever a pallet’s code changes, by matching a git commit hash or similar to notify a docs maintainer/create an issue that some pallet’s code has been changed.
Couple this with proof the pallet currently is deployed on Polkadot, this way, some source of truth backed by code is maintained.
While someone could just argue to go read the code, not everyone who wishes to know how these pallets work would be technically inclined to do so. Besides, while certain elements may change, some of these pallets have functionality that will mostly stay the same from a game theory point of view.
Please share any rigourous presentation of these design decisions. One common use of game theory is around the design of oligopolies and cartels. Specifically, can regulators design incentives to prevent an oligopoly from operating as a cartel, can it create incentives for a cartel member to break a cartel, etc.
Of course cartels can use the same ideas to design a more robust cartel.
It would be interesting to learn just how game theory has been used - @shawntabrizi ?
I don’t believe this ‘fear’ is unfounded. Your analysis ignores the fact that winning the next auction depends on you ‘getting lucky’ in the random selection of the winner - the candle feature of the auction process.
Furthermore, even if you removed this ‘feature’ of the auction you could still lose so long as your ‘chain-business’ was less profitable/funded then the chain winning the last slot.
Or it proved they got unlucky - who wants to build a business on that foundation? Clearly many people do. However, other people don’t, and I’m not convinced that vaguely waving hands in the general direction of game theory will convince them otherwise.
Or it proved their chain gained less traction than some chain(s) that likely are from a different industry - in fact their business may have exceeded every expectation and be their industry leader and that could still not be enough - some other industry with higher margins and/or lower competition could push them out.
Aren’t you misrepresenting the nature of parathreads? Or have I misunderstood them?
I believe they are categorically distinct from Parachains - Parathreads do not guarantee inclusion of a transaction in a block. Parachains do.
For some business use cases that distinction does not matter.
If my understanding is correct, I don’t believe you can treat them as substitutes in the way you suggest.
While thinking about a tutorial idea about FRAME, and came up with an interesting example that showcases/categorizes the scalability issue in blockchains, which is somewhat entangled with game theory. Here it goes.
Imagine a simple validator selection system whereby:
anyone can call bond(amount), which registers them as "wanna-be validator’ with amount as their approval-stake.
anyone can call delegate(who, amount), which increases the approval-stake of who by amount.
every x blocks, we want to get the top x wanna-be validators based on their respective approval-stake (to the best of our abilities).
This is an extremely simple problem in the context of more information systems, but it is a surprisingly hard problem to solve in blockchains. Let’s explore why.
The answer really boils down to one root issue: Blockchains, unlike all almost many other information systems, are not sybil-resistant. When you are thinking about solving the above algorithmic problem, you must assume you are solving it for an infinitely large input size. In this case, this translates to an infinitely large number of wanna-be validators.
The first step in solving such issues is acknowledging such issues, and finding the boundaries of where your system breaks. For the above example, assume that an analysis on weight, memory or state usage could help us conclude that the system would work for as long as there are less than V_max wanna-be validators registered in the system.
In essence, the problem can be stated as sybil-irresistance -> scalability issues. In written words, blockchains are not sybil resistance, therefore face scalability issues.
We can tackle this issue in both sides of the above arrow.
To fix/improve the sybil-resistance part:
Crypto-economics: This means, the deposit to become a wanna-be validator must be high enough such that the cost of registering V_max wanna-be validators is so high that no sane human/attacker would ever do it.
Permissionless operations: The system is not sybil-resistant because it is permissionless and anyone can spam the system. But, that also means anyone can clean aka. de-spam the system . In the above problem, imagine the chain would keep a linked-list of wanna-be validators, and allow anyone to submit an extrinsic that would swap two nodes in the list, as long as it is a positive step toward keeping it sorted. Crucially, if the extrinsic is successful, the submitter gets a (possibly small) reward, that could come from the deposit of the wanna-be validator that was misplaced.
This approach almost always goes hand-in-hand with crypto-economics, and would significantly lower the deposits needed to make sure V_max is never reached. For example, if we solely rely on crypto-economics, we probably have to impose a relatively hefty deposit to solve the above validator selection problem. But if we also rely on permissionless-operations, the deposit only needs to be high enough such that it is enough incentive for someone to submit those sorting extrinsics!
Other Web3 primitives such as DiDs, PoPs and NFTs. There is a broad category of other primitives out there that, if themselves implemented correctly, can de-sybil the system. In our example, this translates to: making sure only accounts that have a particular identity, NFT, or personhood proof attached to them can become wanna-be validators. These systems could be enough to give you credible guarantees that V_max will not be reached.
Polkadot’s Staking system in fact implements a linked-list like above, you can read more about it here.
Note that neither of these solutions attempt at really solving the scalability part. They don’t help increase V_max. They merely help with making the system more sybil resistance, ie. knowing that V_max is (almost) never reached.
Oftentimes, you want both. You want to be somewhat more sybil resistant, but you also want to be more scalable. Imagine you have implemented some or all of the of the above, but simply want that V_max to be larger. This translates to “more blockspace” and typically there are two ways to improve it:
Blockspace optimization. This is a realization that blockspace is a valuable scarce resource, and its usage can be avoided, if possible. Imagine, given input X and output A, a function F(x) -> A and verifier function V(A) -> bool which can verify the output to be correct. We have two options: run F onchain, which needs no verification because the code is trusted. Or else, run F(x) offchain, where none of these scalability issues exist, and submit A back to the chain, and run V(A) onchain. Depending on the complexity of F, V and the size of x and A, it might be the case that doing the latter is more efficient. This realization is the basis of the rollup space. Specifically, ZK-rollups fit the above description perfectly. I would leave it up to the reader to tinker on whether the above sorting problem can also leverage this optimization or not (and comment their thoughts).
Blockspace scaling: Another solution is to simply leverage more blockspace, which one can do by writing operations that are multi-block. This also increases the maximum limit of V_max that is acceptable by the system, yet poses its own set of problems.
Recall, all of this helps us achieve a higher V_max for the above problem, neither try and prevent spammers to fill the entire space of V_max.
on-demand parachains (fmr. parathreads) do guarantee inclusion as long as someone is able to place an order for the marginal price of blockspace at the spot price. The only difference between the two is whether blockspace is being purchased in bulk or on a block-by-block basis. The consensus security guarantees are the same.
this is off-topic, though, but discussions about how to improve bulk blockspace offerings are welcomed in one of the other threads for that topic.
The challenge here is that this is also a definition of economic inefficiency - using enormous amounts of capital to secure transactions of much lesser value - PoS is an interesting first pass at the problem, and permissioned PoS chains are a more capital efficient workaround until a solution emerges.
I don’t see how this establishes that game theory is required.
I agree that well designed incentives can solve or ameliorate such problems. I don’t yet see the need for game theory. Won’t a nonsatiation axiom suffice here? As you note, you simply have to keep bumping up the incentives until you get the sorting submissions you desire.
Of course we could add more scaffolding, but we usually only take on that burden/restriction for some benefit. You identify one objective “lower the deposits needed to make sure V_max is never reached”. But that still doesn’t establish that a solution to this problem requires the additional baggage game theory brings.
Agreed, economic incentives often work too inefficiently to be tolerable IRL, and you have to directly solve the problem in a way that is more expensive, or has otherwise undesirable side-effects e.g excluding people who don’t have the accepted documentation. But this observation also militates against use of game theory.
I don’t disagree with any of that, and I likely don’t yet understand it all. However, I don’t see how that motivates the use/introduction of all the additional scaffolding supporting game theory.
I believe it is uncontroversial to say that blockchains/blockspace increase the equilibria that are supported compared to a non-blockchain world - the introduction of collusive equilibria being the trivial example.
What would seem to be more controversial is to point out that almost always those additional equilibria are a-bad-thing™. Yes, game theory can help understand how those additional equilibria come about. Again we generally use such knowledge to thwart that behavior.
Where the additional blockchain/blockspace equilibria would be a good-thing is when it introduces a classical competitive/Pareto optimal equilibria, where that was not possible without a blockchain/blockspace. You can set this up as a game. However, these have generally been described most productively using representative agent models where the equilibrium dynamics are well understood - and most game theory tends to focus on non-PO equilibria. But, to return to the OP, that would be telling the story of the absence of game-theory behind the FRAME pallets.
Update:
Is it possible that when people say “game theory”, they actually mean “economic/financial incentives”?
Here the question would still be, for example: do you really need all the extra scaffolding required to set up a utility function, rules of a game etc. Or is some simpler setup sufficient, e.g. a nonstatiation axiom, etc.
The following establishes that while you can often show that a game equilibrium exists (Nash), you can’t appeal to a similarly universal statement that efficient dynamics enjoy the universality of Nash’s existence theorem
Yes, at least in my thinking and posted answer, I interpreted “game theory” as economic incentives, which is probably not very accurate use of words from my side.
. In the above problem, imagine the chain would keep a linked-list of wanna-be validators, and allow anyone to submit an extrinsic that would swap two nodes in the list, as long as it is a positive step toward keeping it sorted. Crucially, if the extrinsic is successful, the submitter gets a (possibly small) reward, that could come from the deposit of the wanna-be validator that was misplaced.