Attestation based ticketing system that is managed by Ethereum smart contracts and integrated with pretix. Re: RFP-1: Onchain Ticketing

Devcon Improvement Proposals (DIPs)
1

Hi everyone,

It was really exciting for us at AlphaWallet to see that DEVCON 6 is looking to adopt Ethereum based tickets, as we have already implemented Ethereum based tickets for other events.

Proposal
Our proposal for DEVCON 6 is to use an attestation based ticketing system that is managed by smart contracts and integrated with pretix.

  • Tickets would be distributed to the attendee’s email account, along with the purchase confirmation email. The ticket has a QR code and a link with the same content. The QR code/link contains a signed attestation from DEVCON that binds the ticket with the user’s email address.
  • Crypto users will be able to associate his or her Ethereum address with their ticket, using a DApp browser, in order to use blockchain for voting, receiving free or discounted crypto etc.
  • Non-crypto users can use the QR codes to access the venue and still have access to all the services provided through a traditional ticket

Attestation Based Ticketing
Attestation based ticketing ensures privacy, flexibility and cost efficiency for the blockchain implementation of ticketing. It involves two attestations:

  1. Attestation linking ticket with an email address (provided by ticketing system at the time of purchase of the ticket)
  2. [for crypto users] Attestation linking Ethereum address with email address (acquired by the user through a DApp browser)

image001 (1)
image001 (1)1025×469 68.6 KB

Attestation #1 is the ticket. Attestation #2 is to be issued by http://attestation.id

The process of acquiring attestation #2 would be a simple guided process for the users. It will be through visiting a website, where the user will have to verify their email to receive an attestation that will be saved in the Dapp browser as a cookie or in the user’s wallet if the wallet can recognise attestations.

When the user wishes to interact with a smart contract function, such as voting, the user will call the smart contract providing 1) the email address attestation; 2) the ticket attestation on that email address. Together they prove that the transaction sender’s Ethereum address is that of the valid attendee. Such an implementation would preserve the privacy of the user, as these attestations do not reveal the actual email address. Please check out the safe protocol for more details.

Advantages
The advantage of such a design is:

  1. Ethereum address is optional for those who don’t want to use blockchain at all.
  2. For users who link a ticket to his or her Ethereum address, the process to bind that with the ticket is independent of the ticket issuing process. The buyer can get the needed email address attestation before or after purchasing Ethereum tickets.
  3. If the user loses his or her wallet, then the user can redo the process to get a new email address attestation of the original email.
  4. The ticket can be made tradable within rules specified by the smart contract.

Suitability for DEVCON 6 requirements

  1. Integration with pretix: the system is to be built through providing a module or customising Pretix, which is already a mature ticketing system. This will be done through a collaboration between pretix and AlphaWallet team.
  2. Payment with Crypto, Fiat and stable coins: Possible as the solution will be integrated with Pretix, which already supports these features.
  3. Build for all: The blockchain functionalities are opt-in. The ticket & the associated QR code/link distributed through email can behave as a traditional ticket.
  4. Support for different ticket types: The ticket can support any and all ticketing types, including but not limited to - general admission, discounted and free tickets.
  5. Limiting the ability to resell: The tickets’ resale-ability and tradeability can be restricted through the smart contract.
  6. Ability to purchase more than one ticket. Yes, attendees can purchase more than one ticket.
  7. Sybil Resistance Mechanism: Would be restricted through email
  8. Refunds and Automation: Can be automated for crypto users through smart contracts. Non-crypto users will have the same functionality as that offered by Pretix
  9. Ability for teams to grant special services: tickets can be used to claim special discounts and services. As the ticket can be easily verified by any services without going through any centralised trusted 3rd parties, tickets can be used as the integration point for any other services.
  10. Check-in process: The ticket usher app developed by AlphaWallet team for FIFA and UEFA supports the user to check-in without internet & can be integrated with Pretix
  11. Quality Experience: The AlphaWallet team’s experience in implementing VIP tickets for FIFA and UEFA on Ethereum, will ensure that the ticket experiences for attendees and organisers will be world-class
  12. DIP-0 requirements: Yes, will submit a DIP draft soon.
  13. Interoperability: The solution can be integrated into on-chain, off-chain or hybrid implementations. The exact approach can be designed after understanding the implementation of raffle and auction mechanisms.

Response to Outstanding Questions

  • Token Standard: Our preference is to use 721 compatible standards, as most of the infrastructures support 721
  • Sybil resistance mechanism: Email
  • ZKP and privacy of Ethereum addresses: The Ethereum address is associated with the email through attestation. The ticket is linked with Email in attestation(off-chain, no privacy issue), Email is linked with Ethereum address( off-chain, no privacy issue), Ethereum address can be linked with Ticket(Onchain), can be further improved by applying ZKP in attestation verification
  • Cheap transfers and interactions: Ticket sales do not require on-chain transactions unless the user wants to pay using crypto. Majority of ticket usage does not require on-chain transactions. Only when the user wants to transfer or resell the tickets, they or the buyer need to pay a transaction fee. The fees can be further reduced by using xDai or similar side chains, but it will break the Interoperability with other mainnet smart contracts, eg using Devcon tickets as collateral to borrow money.
2

Thanks Victor & team!

This looks awesome, I love all the detail! A few questions I personally have:

If an attendee loses control of their email, then they lose control of their ticket? If so, that’s no worse than our current exlcusively-email-based solution today, but how is it better?

.

In the check-in process, the attendee would need to show their QR code from their email or their attestation in their Ethereum wallet? Just one, both, or neither?

.

  1. So there is no way of linking the attendees Ethereum address or Devcon ticket with their email, right?
  2. But if you know an attendees Ethereum Address you can find their ticket and visa versa?
  3. Thus, if someone votes using their devcon ticket attestation, anyone would be able to link that vote with an Ethereum address, but no one (including the Devcon team) could link their vote to their email. Correct?

.

Is there a true need for the user to do two attestations? Would one email -> ticket attestation be good enough? It seems it would simplify the user’s workflow.

In the event of a refund of a ticket, how could we ensure that the old ticket is invalidated? Is that accounted for in this system?

All in all — awesome idea IMHO. Excited to hear your thoughts on the above, and more thoughts from others.

1 Like
3

If an attendee loses control of their email, they may lose the capacity to use smart contract functions like voting or trading. They can still attend the event as the event requires no more than the physical possession of the attestation. This was to stay compatible with a blockchain-less scenario.

If the attendee still wishes to access smart contract functions after losing control of email, there are two possibilities:

  1. They previously had an email address attestation that has not expired (say, 7 days). In that case, they can still transact, and they should do so immediately to transfer his attested ticket to their own Ethereum address. The smart contract revokes the attestation and grants a new NFT to the user.
  2. They can convince DEVCON to make a new ticket for their new email address, paying the cost of revoking the one to the deny-list in the smart contract.

The “Better” part in OP is that the attendee can associate his ticket with his Ethereum address and do transactions after purchase, wherein the previous solution you have to either issue an email ticket or a blockchain ticket. The flexible part means that he can acquire email address attestation before or after purchase, and if he loses that attestation he can always get another; if he loses his wallet (say he is a newbie) he can also restart from the ticket attestation and associate it with a different Ethereum address. The “cost” part means Devcon sends no transaction when issuing a ticket even if the user intend to use it on the blockchain later.

  1. If the attendee purchased the ticket from devcon, email + static QR code should do.
  2. If the attendee acquired the ticket from smart contract trade, he would not have the attestation, but an NFT instead. In this case, he use a dynamic QR code in mobile wallet to prove his knowledge of the key. The usher checks the ticket against a smart contract. The usher needs to be connected to the blockchain. The attendee doesn’t have to.

An observer (adversary) can link a Devcon Ticket to an Ethereum address but he cannot link email address or learn what is (any of the) email address. The zk is part of an attestation protocol to protect the identifier (email addr), not protect the ticket/address linkage like Tornado does to balance/address. This is because the zk part is baked into the lower level identifier attestation protocol but the ticket is a higher level protocol on top of it. Protecting email address is a bottom-line, but protecting higher level ticket - I would think it optional.

If the attendee used it on the blockchain (like voting), you can observe the blockchain and learn which ticket has voted, but not the identifier (email) that links the ticket to the Ethereum address.

if someone votes using their devcon ticket attestation, anyone would be able to link that vote with an Ethereum address, but no one except the Devcon team could link their vote to their email.

Devcon team can link their vote to the email because the ticket ID is not cryptographically hidden and devcon team has ticketID<->email data in the Pretix. We know we must protect email addresses, but further hiding ticket ID is a discussion of benefit vs complexity. The method to do so is well known in the secure voting cryptography, but whether it justifies the engineering effort…

Only users those who want to use smart contract need the 2nd attestation, otherwise, the smart contract can’t tell if the transaction sender is the email owner just by looking at email->ticket attestation, and any observer can front-run such a transaction by claiming they also have the emai->ticket attestation.

The smart contract has to maintain internal knowledge of invalidated ticket attestations anyway, since such a deny list is needed when someone trade his ticket with another (therefore invalidating the first person’s ticket attestation and creating a NFT for the second person).

I hope the info is useful from a technical prospective.

  • Weiwu Zhang (I’m not Victor - Victor Zhang is the CEO, I’m the CTO)
1 Like
4

DIP submitted

2 Likes
5

As the ticketing DIP RFP deadline approaches (tomorrow) I gave this DIP a deeper look.
First of all: I like this DIP and will support it (not the only one making this decision - but I will vote yes as I like the idea)
But we need to talk about some details. One thing that puzzles me a bit the DIP states:

On top of that, an email attestation service for uses needs to be built. We (AlphaWallet) can create one such service for attendees to claim attestation #2 (explained below) at http://attestation.id,

This link currently leads me to a DEX - wonder what exactly the connection is. (and btw. we should do http->https here)

ideally to create a decentralised ecosystem of attestors for the benefit of enriching smart contract functions and reducing on-chain transactions. These attestations can be reused.

wondering about “reducing on-chain transactions” here. Can you elaborate how on-chain transactions are reduced?

Also would be great to get some use-cases for Attestation #2

6

Dear @ligi you wrote:

The domain acutally links to my personal test build space. I put a place holder there to say that when built this domain will be used for attestation service, but a few weeks later I used it to test DEX code → now reverted back.

Sorry that was just my personal staging server so that’s when I worked on the DEX (it’s in the news - αWallet partnered with a DEX). I now use a different staging server so this won’t happen again.

Wondering about “reducing on-chain transactions” here. Can you elaborate how on-chain transactions are reduced?

Yes. First, you can issue 1,000 ticket attestations (we call it cheque internally in the code - meaning redeemable rights or value) without sending any transaction, therefore saving 1,000 transactions. Then, suppose you resell it (current DEVCON didn’t ask for this but reselling is valid in other use-cases), you send another cheque for the buyer to redeem the ticket at a certain value (e.g. the buyer has to attach 10Ξ to redeem the ticket), this is done in 1 transaction instead of 2 (one offering and one finalising; or one sends the ticket and another sends the payment)

Also would be great to get some use-cases for Attestation #2

Yes. So you probably know that I had been architecting a bank’s blockchain experiments (CBA, invested 40-mils on blockchain capability). A pattern observed repeatedly in business use of blockchain was transactions on identifiers. So in today’s Etherum world, your key is your identifier - addresses are hashed public keys. But this doesn’t work when business is involved. Reasons:

  • Accountability of keys. If an employee leaves you can’t be sure that he didn’t copy the key. What you do is to keep the role but associate it with new keys.
  • Business process. Usually, you have customer_id, member_id, supplier_id already, and these are designed to not to mutate; replacing them with hashed pub_key breaks too many databases.
  • Integration. many systems have to work without blockchain and plug in at a certain point. It may generate a key when it needs blockchain. It may leave the key generation to a lower-level process than it’s core business flow (consider opening a service account for a customer - he has no keys before he installs the service app).

So many transactions have to be on an identifier, not on a key, and these identifiers have to be cryptographically hidden. The protocol we made to solve this is explained on a low level (crypto protocol level) here.

I know this may sounds “businessy” to our community of volunteers and opensource folks, but it’s not that “businessy” if you think about it. Think DevCON, it already faces the problem of wanting to issue crypto tickets with a process separated from how / when the user wants to use them on the blockchain, and it already wants to keep using the email address identifier even before we introduce our protocol. Evidently, the pattern is not specific to the business process discovered in banks’ experiments. Oh, and we planned to ues this pattern for UEFA ticket thing which got cancelled.

1 Like
7

thanks for the reply!

follow up questions: is 1000 a fixed number or just an example? If so: Is there a maxima?
Regarding the use-cases I would like to see more concrete examples. Meaning something like “As a Devcon attendee I can use the attestation to do X”

8

1000 is just an example, the actual number is the number of ticket sales. There is no max number as the attestations are issued off-chain (to be used on-chain).

As to the use-cases, that would be:

As a devcon attendee (who has ticket attestation)

  • I can use the attestation to vote for speakers on the blockchain
  • I can use the attestation to vote for speakers on a website (the website can collect the votes later to be used on the blockchain or simply tally it on the website)
  • I can purchase from a discount token sales
  • I can log in to a 3rd party website with my attestation instead of username/password
  • I can participate privileged token presales by showing my attestation and let the speaker of that token attest to it, and later taking both to the pre-sale smart contract.‡

As a user with identifier attestation (the other attestation based on e.g. email)

  • I can login to a website with an identifier (email)
  • I can receive cheques redeemable by that identifier (email)

Imagine you send your friend bob@example.com some tokens as Christmas gift to encourage him to go crypto. You can’t send directly because he hasn’t created an Ethereum address yet - even if he did he will have lost the key. Sending him a cheque redeemable by bob@example.com gives him the opportunity to use identifier attestation later. If he never redeems it, the money (token) is not lost or locked up forever.

All these require library support.

  1. A JavaScript library is to be included in any website that authenticates the visitor by attestation. For example, an online shop selling souvenirs at a 50% discount to ticket holders.

  2. An attestation.sol is to be included in any smart contract (e.g. token pre-sale) which allows e.g. the use of a modifier† attestationIsValid such as

    function vote(uint8 choice, bytes voterAttestations, bytes proof) public attestatioIsValid {
    }

† Pending smart contract design. We have the smart contract to validate attestations but we never made a library before - can use some community help here.

As part of the project plan, αWallet plans to deliver:

  • The library for smart contracts to include.
  • The library for websites to include.
  • An example (1 page only) ticket issuer website.
  • An example (1 page only) 3rd party website (e.g. souvenir shop).

‡ In practice, you can show your attestation as QR code with a compatible wallet and ask the speaker to sign it by scanning it and send you a magic link with some sort of authorisation/consent, which awards you the 2nd attestation linked to the previous one, together forming the chain of proof that you were in the event and was granted the privilege to buy presale token. There are protocol components but the actual code for this usage flow is not written yet.

2 Likes