CIP-???? | Affirmation Graph #938
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,126 @@ | ||
| --- | ||
| CIP: ? | ||
| Title: Affirmation Graph | ||
| Category: Tools | ||
| Status: Proposed | ||
| Authors: | ||
| - Kieran Simkin <hi@clg.wtf> | ||
| Implementors: [] | ||
| Discussions: | ||
| - https://github.com/cardano-foundation/CIPs/pull/938 | ||
| - https://forum.cardano.org/t/introducing-the-affirmation-graph-request-for-comment/138320 | ||
| Created: 2024-10-26 | ||
| License: CC-BY-4.0 | ||
| --- | ||
|
|
||
| ## Abstract | ||
| We need a truly decentralized alternative to KYC for when we need to establish the authenticity of a wallet or make some judgement about its trustworthiness in a systematic and repeatable manner. This CIP defines a mechanism whereby any member of the community can publicly vouch for the authenticity of a wallet by submitting an "affirmation" transaction, it also provides a mechanism to revoke such an affirmation, if, for example a wallet becomes compromised, or its owner turns out to be a charlatan. | ||
| It is consequently possible to observe the current UTxO set and draw an "Affirmation Graph", a multidigraph representing the trust relationships between wallets - we can then use an algorithm to assign trust rankings and decide whether or not to trust an unknown wallet. | ||
|
There was a problem hiding this comment. The statement about using an algorithm to assign trust rankings introduces a potential vulnerability. If the specific algorithm used to assign trust values to wallets becomes widely known, it could be exploited or “gamed” by malicious actors. This could lead to manipulated trust rankings, undermining the reliability of the system. This issue becomes particularly problematic if users develop a false sense of security, assuming that the trust rankings are inherently reliable or immune to manipulation. There was a problem hiding this comment. This is why the specification and the associated toolchain leave the actual selection of algorithm down to the end user, and it will vary depending on different use-cases. Some users might choose to only trust wallets that have been affirmed by a centralized KYC provider - in this case the security guarantee is equal to that of the KYC provider. Others might choose to trust only people affirmed certain select individuals, but in this instance you would be assuming those individuals had not been compromised. I will add some caveats to explain the potential pitfalls around this. |
||
|
|
||
|  | ||
|
|
||
| ## Motivation: why is this CIP necessary? | ||
| When transacting with an unknown person, currently if we want to make sure we're not dealing with a bot or a grifter, we have to perform our own detective work - examining their current token holdings and transaction history, then we make some informed guess about what we're dealing with. This is both laborious and inconsistent. This CIP aims to provide a better alternative which is repeatable and automatable, this could drastically reduce the risk of fraud and accidental loss of funds. | ||
|
There was a problem hiding this comment. The claim that this CIP could "drastically reduce the risk of fraud and accidental loss of funds" feels overstated. While it makes trust evaluations more systematic and repeatable, it does not eliminate risks like system manipulation or false trust. A more balanced phrasing might highlight that it complements manual diligence rather than fully replacing it. Something like "This CIP proposes a decentralized mechanism for assessing wallet trustworthiness in a systematic and repeatable way, aiming to reduce the effort and inconsistencies of manual evaluations. While it does not eliminate risk entirely, it provides a new tool to complement existing approaches to fraud prevention." There was a problem hiding this comment. I'll take that wording :) Thanks. |
||
|
|
||
| Now that we are in Cardano's Voltaire era; governance is top of the agenda, it would be really nice to be able to hold ballots where each community member gets an equal vote - true democracy requires it. Currently all voting is stake-weighted - ie. 1 Ada = 1 vote - this results in a plutocracy, not a democracy. In order to deliver a fair democracy, we must have some way of identifying unique individuals. Traditionally this would be done with KYC - each voting participant would be required to identify themselves with some form of government ID - however, this relies on a central authority having issued the ID, and another central authority verifying it. It also excludes people who wish to (or must) remain anonymous for whatever reason, as well as those who may not have any government ID, perhaps because they are stateless. | ||
|
There was a problem hiding this comment. While I understand the desire for an alternative to stake-weighted voting, I believe this solution is not suited as a foundation for governance voting. Given the outlined security concerns and the probabilistic nature of this system, it can only serve as a complementary tool, not a reliable basis for ensuring fair and secure voting. There was a problem hiding this comment. @perturbing does this also mean that malicious user(s) could exploit such a system to influence the outcome? I read your comments for such a statement & perhaps it's implicit in what you wrote, but if true I would prefer to also record this literally. I had made some prior comments (here and on the Cardano Forum) suggesting this tool might be usable for analytical purposes even if votes were not conducted with it. But any procedure for exploit would invalidate (or require strict disclaimers on) even this use case: since the more valuable the "affirmation" the more likely that people would try to game the outcome. There was a problem hiding this comment. Well, it depends on how the algorithms are defined and who uses what. But yes, I think this can approach can be “gamed” or influenced in an unintended way. I do not think the idea is invalid because of this, just that it should be apparent what such a tool brings (and what not). IMO, this is definitely not a tool for governance voting. There was a problem hiding this comment. The devil is really in the detail of how you interpret the graph - in the most simple case where you're basically just adding 1 to the trust score for every affirmation that a wallet has - there's definite potential for abuse with that. However, in a lot of cases, that might be "good enough". The exciting bit for me is when you start building complex algorithms for interpreting the graph - the Affirmation Graph indexer that I'm building gives quite a lot of information that can be used to inform these algorithms. For example, the date when every affirmation occurred, the date of a each wallet's first ever transaction (of any kind), smart contracts that wallet has interacted with (and frequency), native tokens held by that wallet etc. So this would enable you to implement certain safeguards - say, de-weighting affirmations from any newly created wallet. You can also use graph theory to detect new clusters, or isolated clusters that are not strongly interwoven with the rest of the graph. You could also detect unusual behaviour that might result from a compromised wallet - for example if a wallet suddenly starts issuing lots of affirmations outside their own local cluster, and to relatively new or untrusted wallets. Members of the various factional communities on Cardano (mostly centred around NFT projects) will be able to bias their judgements in favour of members of their own community - giving their affirmations a higher weight. OR you could choose to ignore the opinion of anyone who holds a particular meme coin that you may dislike. The power is in allowing people to design their own graph interpretation algorithm - I may even create a visual algorithm-builder, such that even non-technical users will be able to design and customize their own algorithm, and encode their own personal biases within it. I have also thought about using machine learning to further augment the safeguards - once the graph is established and we have some examples of good and bad actors, it might make sense to train an AI to detect bad actors. It might even be capable of predicting rug pulls before they happen. However, I'm personally philosophically a bit wary of bringing AI into what is basically a social experiment on trust - it could get dystopian pretty quickly. But once the graph is there, someone is bound to use AI to interpret it - opening that Pandora's box is inevitable. I take on board the points about scaling back some of the claims, and adding caveats around potential pitfalls, and I will redraft the CIP with this in mind. However, it is still my belief that this system can and will become equally, if not more trustworthy then traditional KYC. After all, you can buy a fake identity that will pass KYC on the darknet for a few hundred dollars - circumventing KYC is trivial to someone who knows what they're doing - it's one big single-point-of-failure. What would not be trivial, would be convincing a significant number of respected and established community members to literally stake some Ada on me as a person - sure, people can often be bought, but if it becomes apparent that a community member is consistently giving dodgy affirmations, that community member's trust rating can be expected to take a nose-dive. Or put more simply - I trust the community more than I trust the government - within the scheme I'm proposing, the government effectively becomes another member of the community, and it's up to the individual to decide how much weight they place on the government, versus their close circle, versus any factions they're a member of, versus the opinion of the wider community. The first step is building out the graph - ie, allowing people to give each other affirmations (I am very nearly ready to launch this). Initially I will not be deriving any trust ratings from it - I'm simply going to allow people to view their place on a network diagram. I anticipate that it will take some time for the graph to become established before it will be useful for actually determining trust scores, and there is no rush to do that - I won't start assigning trust scores until the graph is rich enough to contain useful information - it's better to do nothing than get it wrong! |
||
|
|
||
| If we are to bank the unbanked, we should also provide ID for those who have none. | ||
|
There was a problem hiding this comment. While I agree with the sentiment of the statement, this CIP does not actually propose a solution for providing such an ID, making the inclusion of this line somewhat misleading. There was a problem hiding this comment. Perhaps I should explicitly state that we're basically treating stake keys as DiDs here, and a stake key with a high trust rating is a form of ID in itself. I do understand the potential for confusion here though so I will clarify. |
||
|
|
||
| In this CIP we propose a simple, truly decentralized mechanism for identity verification and trust. | ||
|
There was a problem hiding this comment. The claim of a "simple, truly decentralized mechanism for identity verification and trust" feels overstated. Based on the issues raised in my earlier comments, this CIP provides a mechanism for probabilistic trust relationships, which is not equivalent to robust identity verification. A more accurate phrasing might clarify that it offers a decentralized tool for assessing trust rather than verifying identity outright. There was a problem hiding this comment. It does also support robust identity verification in the form of affirmations by KYC providers. In fact it makes these KYC verifications portable so that you only need to do KYC once and it's portable to any dApp on Cardano. |
||
|
|
||
| ### Why does this require a CIP? | ||
| We are aiming to create a scheme which is generic and becomes the accepted standard for registering your affirmation of a particular wallet, such that everyone may participate and we can be sure that there is one definitive affirmation graph for the blockchain and that all affirmation transactions will follow a consistent format. As such, a defined standard that everyone can follow is necessary - a CIP is the way to acheive this. | ||
|
|
||
| To that end, a smart contract conforming to this specification has been defined which attempts to be the most simple and generic possible. No fee is required (aside from the inherent blockchain fees), the smart contract contains nothing specific to the author's websites or implementation. It is designed so that it can be integrated into any blockchain explorer, wallet or dApp. It is expected that the majority will use this generic smart contract, but it's also possible to define your own smart contract that is compliant with this CIP - it must meet the specific requirements detailed below. | ||
|
|
||
| ## Specification | ||
| [v1 of the affirmation contract](https://github.com/kieransimkin/affirmation-graph/blob/main/validators/affirmation.ak) | ||
|
|
||
| Definitions: | ||
| `target` - the recipient of the affirmation | ||
| `source` - the creator of the affirmation (the person or entity who is vouching for them) | ||
| `target hash` - if the `target` is a normal wallet, this should be their stake key hash. If the `target` is a script, this should be the script hash | ||
| `source hash` - if the `source` is a normal wallet, this should be their stake key hash. If the `source` is a script, this should be the script hash | ||
| `affirmation contract` - any smart contract which conforms to this specification (details below) | ||
| `contract hash` - the hash of the `affirmation contract` | ||
| `affirmation address` - An address where the spending part is `contract hash` and the delegation part is `target hash` | ||
|
|
||
| An affirmation consists of a UTxO at the `affirmation address` with an inline datum containing the `source hash`. To be valid, this UTxO must contain one token minted by the `affirmation contract`, and the `affirmation contract` itself must be valid as defined below: | ||
|
There was a problem hiding this comment. Why not use transactional metadata? It is an old discussion, but good to ask again and again, why is it needed to have the data in the active UTxO set? There was a problem hiding this comment. Mainly so that you aren't required to run a chain indexer in order to have any visibility on the graph. The idea is that trust ratings would be presented in wallets, and the wallets themselves would generate those ratings directly from the UTxO set. I have made an effort to minimize the size of the datum - that's why the included smart contract is written to allow two different datum specs - the default and most simple one contains only the public key hash of the person giving the affirmation - this is the datum that is expected to be used in 99% of cases. Unfortunately the script does also require minting a kinda pointless token - but this is just a necessary trick to get Cardano to perform validation upon creation of the affirmation UTxO, since Cardano does not otherwise perform validation upon creating a UTxO - I wonder, is there a CIP for that? There was a problem hiding this comment.
@fallen-icarus this sounds familiar & I think you've covered that realm... would you recommend any approach either from a merged or candidate CIP? There was a problem hiding this comment.
I've only briefly looked at this CIP so apologies if I am misunderstanding something. If you don't care about the token, then perhaps the "withdraw 0 ADA" trick would be better. You would use a staking script to validate the new affirmation UTxO; the script will be executed as long as the amount of ada withdrawn from its staking address is >= 0. CIP-112 was created to add a dedicated "observe script" type which would be cleaner than even the "withdraw 0 ADA" trick. Another possibility is to use the token itself as a stamp of validity: the token can only be stored in the UTxO if the UTxO is properly constructed. Then the indexers can just filter the current UTxO set by those that contain these tokens. Off-chain indexers make this very easy; they usually have dedicated "Asset UTxOs" endpoints (maestro, koios). This would provide more secure indexing than just using the affirmation address since it is possible to create invalid UTxOs at the address without executing the minting policy or staking script (ie, addresses can't deny UTxOs). It is quite old but the beacon token CIP explains how to do this in a trustless setting; but if you think you can trust the UTxO creator, an adaptation of CIP-68 may also work. |
||
|
|
||
| A valid `affirmation contract` _MUST_ allow minting exactly one token at a time. In order to mint: | ||
| - it _MUST_ ensure that it receives a signature matching the `source hash` or is otherwise authorized by `source`, | ||
| - it _MUST_ ensure that the output containing the newly minted token contains an inline datum with a matching `source hash` and | ||
| - it _MUST_ ensure that this output it sent to an address where the spending part is equal to the `contract hash`. | ||
|
|
||
| In order to enable revokation, the contract should allow spending. When spending, the contract: | ||
| - _MUST_ ensure that it receives a signature matching the `source hash` in the datum, or is otherwise authorized by `source` and | ||
| - _MUST_ ensure that exactly one token matching the `affirmation contract`'s policy ID is burned. | ||
|
|
||
| A generic `affirmation contract` has been provided which meets these requirements - you should use that unless you have specific requirements which are not met by that script. | ||
|
|
||
| It should be noted that if you do write your own custom `affirmation contract`, your affirmations will not automatically be picked up by the [affirmation graph indexer](https://github.com/kieransimkin/affirmation-graph-index) - this is because the indexer maintains a list of known valid affirmation contracts. If you wish to add your contract to the list you should submit a pull request to the indexer repository in which you must prove that your contract meets the requirements detailed above - only then will your affirmations be included in the global Affirmation Graph. If in doubt, simply use the generic affirmation contract that has been provided as part of this CIP unless you have a good reason not to. | ||
|
|
||
| MeshJS (the Typescript Cardano library) [has been updated](https://github.com/MeshJS/mesh/commit/fbfc8dd922ddf4c4df0d59f5fbd4f260af34da5d) so that it knows how to build these transactions, so you can do it in one easy step if you're in TS/JS. [A Python implementation](https://github.com/kieransimkin/affirmation-graph/blob/main/examples/affirm.py) is also available. | ||
|
|
||
| ### Datum specification | ||
| ```cddl | ||
| keyhash = bytes .size 28 | ||
| datum = #6.121([keyhash]) | ||
| ``` | ||
|
|
||
| Example datum as JSON: | ||
|
|
||
| ```json | ||
| { | ||
| "constructor": 0, | ||
| "fields": [ | ||
| { | ||
| "bytes": "4ec65f9ad80492c187df2d9d7428d5c1fef10de7687cdf9356170816" | ||
| } | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| ### Versioning | ||
| This is version 1 of the affirmation graph specification - any material change in the specification will necesssarily require a new smart contract, which will result in new set of `affirmation addresses`. Consequently an affirmation contract will always target a specific version of the specification. Any new version of this specification should be separately defined in its own CIP. | ||
|
|
||
| ## Rationale: how does this CIP achieve its goals? | ||
| It could be argued that, with enough Ada, it is always possible to create many wallets and then submit affirmations for yourself - thus returning the system to being weighted by how much Ada you have - however, this would be a failure to understand the purpose of a decentralized Affirmation Graph - in a this regime, each individual person is responsible for interrogating the graph to establish a trust score for a particular wallet - but they have complete freedom on how they choose to interpret the graph - for example, you could decide to only trust wallets that have been affirmed by a specific person (perhaps yourself, or a person you know who has affirmed a lot of people and whose judgement you trust), or only trust wallets that have a minimum number of affirmations from anyone, or you could specify that at least two of your friends must have affirmed a wallet. You could even require that a centralized KYC provider has affirmed a wallet - this would allow actual KYC gating in a semi-decentralized manner - multiple KYC providers might exist, and you might choose to give a higher trust rating to some than others, perhaps depending on how thorough their ID verification process is. Other providers might exist which offer affirmations in return for proving you own a unique Facebook or Google account. | ||
|
|
||
| It is expected that there could be a flood of services offering affirmations in return for jumping through any number of different hoops. It is also expected that mutual affirmations will be offered; "I'll affirm you if you affirm me". Stake pools might choose to offer affirmations in return for keeping your delegation with them for some amount of time. None of this does any harm to the value of the graph since we can design our algorithms to sift through the data and derive whatever meaning we please from it - the more we expand the size of the graph, the more we have to work with. | ||
|
|
||
| I would also suggest that affirmations should be given in return for certain "good citizen" behaviours - for example, affirmations could be given to Catalyst participants upon successful completion of their project milestones. Affirmations could also be given in return for participation in voting events, or in return for helping moderate Catalyst proposals. SPOs could receive affirmations in return for upgrading to the latest node version - any behaviour which we wish to incentivise could be rewarded with affirmations - this provides a great way to incentivise good behaviour, whilst also allowing us to judge wallets based on their behaviour. | ||
|
|
||
| The algorithms for interpreting the graph are expected to become numerous and varied - some examples will be provided as part of the Affirmation Graph toolchain, and users will be free and encouraged to build their own and contribute them back to the library. These algorithms will function by assigning a trust score to a wallet, based on a set of weighted judgement criteria - different algorithms will assign different weights to affirmations depending on where they came from. For example, an algorithm that requires KYC verification would assign positive weights to known KYC providers, and zero weights to all other affirmations. A "trust my friends" algorithm could measure each affirmer's distance from yourself on the graph, and weight affirmations from people close to you on the graph highly, with an exponential fall-off as the affirmer is an increasing number of steps away from you on the graph. | ||
|
|
||
| Wallets could choose to display a trust score whenever they prompt you to sign a transaction - this could help users identify if they're dealing with a potential scammer, before they send them Ada. Since smart contracts can also receive affirmations, and consequently can be given a trust score, wallets might also decide to display this score every time you interact with a smart contract. | ||
|
|
||
| ### Could this amount to a form of social credit scoring? | ||
| Well, you could describe it that way, but the biggest problem with social credit is that it's decided by a centralized authority - there's no centralized authority here, it's an egalitarian collective. I think of it as similar to the way we all have an understanding of how reputable we consider a given person - some of that will be biased by our own position, but some people will be fundamentally more "reputable" than others, we all have an instinctive understanding of who we consider these people to be. There is, perhaps, a danger in making something like reputation so publicly visible - generally these reputation judgements are something we do so regularly in real life that it's an unconscious process a lot of the time, and we're often not even immediately aware of why we've judged a certain person as untrustworthy or not. The Affirmation Graph does still give you the privacy of your own judgements though as there's no way to know what criteria you're basing your decisions on. The only thing thing you're sharing publicly is the set of wallets you endorse - this is really no different to a public friend or follow list like you have on most social networks. | ||
|
|
||
| This system allows even a user who wishes to remain completely anonymous to develop a reputation and gain a trusted rating, even if they do not not wish to prove their indentity in any way - if they have an online persona, there will be people willing to affirm them based on that persona alone. Plus, they may accrue affirmations by displaying good behaviour if such behaviour is rewarded by affirmation as suggested. | ||
|
|
||
| This CIP is fundamentally about linking the social graph with the blockchain, so that you can have the same level of confidence that you're dealing with a real human-being as you do on Facebook or X. While this is never 100% certain, I would argue that most people can tell the difference between a real human or a bot on social media with a high degree of accuracy - we need to acheieve a similar level of confidence in our judgements about whether or not we trust a wallet on the blockchain. Only then can we have a hope of implementing 1-person-one-vote and having any meaningful form of democractic system - and that's the end goal; to enable Cardano governance to be truly democractic by removing the biases of stake-weighted voting, and instead move to something more closely representing 1 person = 1 vote. | ||
|
|
||
| We would also have the option of implementing a true meritocracy where a user's voting power is actually weighted by their trust score - so instead of 1 person = 1 vote, we'd actually give stronger weight to those with very high trust ratings - this would work particularly well in a scenario where we were rewarding good behaviour with affirmations, but there would potentially be a risk of power being centralized among a few very highly trusted individuals - for example if we rewarded Catalyst participants for meeting their milestones, we could find that regular Catalyst participants received very high trust ratings which enabled them to outvote everyone else. We'd therefore have to carefully design the weighting algorithm to avoid this - it may be simpler to stick to 1 person = 1 vote, and simply require a minimum trust score threshold in order to verify that a wallet represents a unique person. | ||
|
|
||
|
|
||
| ## Path to Active | ||
|
|
||
| ### Acceptance Criteria | ||
| - [ ] Implementation of "Affirm this wallet" button in a couple of third-party dApps | ||
| - [ ] The mainnet graph needs to have a good number of affirmations in it | ||
|
|
||
| ### Implementation Plan | ||
| - [X] Design and test [the smart contract](https://github.com/kieransimkin/affirmation-graph/blob/main/validators/affirmation.ak) along with its [transaction builders in Typescript](https://github.com/kieransimkin/affirmation-graph/blob/main/examples/affirm.mesh.cjs) and [Python](https://github.com/kieransimkin/affirmation-graph/blob/main/examples/affirm.py) | ||
| - [ ] Get feedback on the smart contract with a view to permanently setting it in stone | ||
| - [ ] A React control to enable blockchain explorers and dApps to easily add an "Affirm this wallet" button. | ||
| - [ ] Implement "Affirm this wallet" into [Cardano Looking Glass](https://clg.wtf/) | ||
| - [ ] Build out [a specialized chain indexer](https://github.com/kieransimkin/affirmation-graph-index) to enable queries on the graph. | ||
| - [ ] Create the first examples of trust scoring algorithms | ||
| - [ ] A React control for visualising the graph as a network diagram. | ||
| - [ ] Build a service which offers affirmations in return for KYC. | ||
|
|
||
| ## Copyright | ||
| This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The abstract sets an ambitious goal by suggesting that this CIP provides a "truly decentralized alternative to KYC." However, the solution proposed—an Affirmation Graph—is probabilistic and does not provide guarantees about a wallet's authenticity or trustworthiness. While the system introduces a novel approach to building decentralized trust relationships, it falls short of delivering the full equivalence of KYC.
Two specific concerns arise from this:
Overstating the Solution's Capabilities: The current wording creates the impression that the Affirmation Graph is a comprehensive replacement for KYC. This could lead to a false sense of security for users who might overestimate its reliability.
Unclear Goal Alignment: If the system inherently cannot guarantee trust, what is the purpose of framing it as an alternative to KYC? A more accurate framing might describe it as a tool for probabilistic trust evaluation rather than a replacement for centralized identity verification.
A possible rephrasing of the opening could be:
"This CIP defines a decentralized mechanism to establish probabilistic trust relationships between wallets, providing a step toward alternatives to centralized KYC mechanisms."
This revision would better align with the proposal's actual capabilities while setting realistic expectations for its use. Additionally, it might be helpful to include a disclaimer in the abstract to caution readers about the limitations of probabilistic trust mechanisms, ensuring transparency and reducing the risk of misuse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not strictly true:-
I will be setting up a service which performs traditional KYC and grants you an affirmation in return. If you wanted, you could only trust affirmations from this stake address, and then you'd have a direct implementation of traditional KYC, within the Affirmation Graph context, so that will provide guarantees about a wallet's authenticity.
Always better to underpromise and overdeliver, I'll take that point.
In my mind, it is a direct alternative to KYC, but founded on the principle of decentralization - it's directly analogous - instead of relying on a central authority, you're relying on the "hive mind".
I agree it's probably sensible to add some note of caution, as with any system of trust really, it's only as reliable as its participants.