Is it possible to differentiate between a real human authenticating and making contract calls versus an AI / bot / code? If so, how could detecting this be implemented?
Detecting a bot could work by finding inhuman patterns, like 24/7 activity. Humans need sleep.
Detecting a real human interaction is probably impossible.
1 Like
another approach is using zero knowledge proofs of humanity linked to accounts. a contract call could have access controls using merkle proofs where the caller needs to provide a merkle proof that they exist in the merkle tree root. this could differentiate bot calls.
1 Like
is there a simpler way to do something similar?
One thought requiring that from the contact-caller have a .btc name and it’s been registered (white-listed)
Bots can own the names also of course, but this adds additional time and $ expense to bots using a large number of addresses. Presumably also, these names can be blacklisted based on some kinda bot detection algo tracking Tx metrics per address.
It’s helpful but not foolproof. Sophisticated bots can mimic human behavior by randomizing a schedule of operations.
Whats the use case?
I have a merkle gating mechanism on testnet - its an efficient way to do white lists. The merkle root is updated via a DAO vote so you can use community to self select humans vs non humans?
Ranking blockchain usage per person. (per real user account).
One project (@friedger pointed out) uses a novel approach to validate human accounts, called “validation ceremonies.” These ceremonies are designed to verify that a participant is a real human being, rather than a bot or artificial intelligence.
Here’s a general overview of how these ceremonies work:
- Scheduled ceremony: A validation ceremony is scheduled at a specific time and date. This ceremony is announced in advance, and participants are invited to join.
- Cryptographic puzzle: During the ceremony, participants are presented with a cryptographic puzzle to solve. This puzzle is designed to be solvable by humans, but difficult or impossible for bots to solve.
- Time-limited: The ceremony is time-limited, typically lasting for a short period, such as 10-15 minutes.
- Simultaneous solving: All participants must solve the puzzle simultaneously, within the allotted time frame.
- Proof of work: The solution to the puzzle serves as a proof of work, demonstrating that the participant is a human being who has invested time and effort to solve the puzzle.
- Validation: Participants who successfully solve the puzzle are validated as human accounts. Their accounts are then marked as “validated” on the network.
The result of the ceremony is a unique digital signature, which is stored on the user’s account. This digital signature serves as a proof of validation, and can be used later to verify that the user is a real human.
When a user attempts to access a service or perform an action that requires verification, the system checks for the presence of the digital signature on their account. If the signature is present, the system knows that the user has previously completed a validation ceremony, and is therefore a verified human account.
The digital signature is also linked to the user’s public key, which ensures that the signature cannot be forged or transferred to another account. This creates a secure and trustworthy way to verify the identity of users, and prevents bots and artificial intelligence from accessing services that require human verification.
By using the result of the validation ceremonies in this way, the project creates a robust and secure system for verifying the identity of users, and ensures that only real humans can access certain services and perform specific actions.
I wonder if the Validation Ceremonies implementation could be simplified by just creating a white-list of addresses deemed human during the most recent ceremony.
How does the community determine human(ity)?
Interestingly the old Blockstack DIDs were a pretty good proof-of-human esp with the address-to-ID attestations on social media sites.
But many users prob would not want to dox their addresses like this.
what do biometric wallets add to this maybe coupled with some version of the zk-login they use on SUI ? Could you have a transaction type that contracts have a baked in way of telling human from other tx types and so contracts can tell just from the tx type ? i think right now, esp. with clarity, we’re need some kind of access control / allow lists / gating in the smart contracts?