EthCC 2: Ethan Illingworth & Angus Hamill

we know this is the last talk so we won't keep you guys too long we're both here representing Aventis i'm ethan by the product team and this is angus my colleague one of the blockchain engineers today we're going to be talking about our scaling solution tackling a specific use case for the ticket delivery industry with a decentralized approach we're happy to go over some questions at the end if there's time so yeah first up let's look at the specific industry context or offering the current landscape is murky for the average ticket goer and supports fan purchasing primary tickets directly from one of the big suppliers is trusted to a point but once you're looking to buy a ticket of our secondary market you're really exposing yourself to a lot of risk you're opening yourself up to being scammed by various actors additionally once a ticket is sold by a primary seller it's then completely out of their control and ownership can be transferred to whomever so there's no way that the primary can keep track and contact the current ticket holder what the start time changes or if you want to circulate a venue change basically as a fan you're trusting that a forward forwarded email that you've just received and paid 100 euros for is legit there's no real way of knowing until you approach the venue gates on the day that the ticket you've just paid for what is is actually legit so this whole thing is not ideal at the moment so here are we Aventis the solution is using blockchain technology to create an opening open ticketing standard for the benefit of both ticket buyers and ticket sellers using the protocol event owners will be able to issue verifiable tickets to fans and set smart rules embedded in tickets to allow control once initially sold ticket buyers will be able to independently verify their ticket without the need for a third party proving ticket provenance even when browsing a secretary I'm yeah so basically we took these problems and we kind of designed an ideal decentralized ethereum solution so basically what you would do is create an event virus small contracts on etherium and register who you wanted to do your primary and secondary cells and then the ticket sales would basically take place that could be a direct payment to chain it could be off chain and then submitted by your primary sellers and so then they would all be going through one transaction at a time the event occurs in real life you create a door list out the public keys of everyone who bought a ticket and then at the door they basically submit some proof that they bought a ticket and then you easy recover that proof get their address and they're allowed in and then you would just simply send a transaction to any event so we designed this we docked up like a proof of concept and then we took it to like big ticketing companies and they basically said it was absolutely rubbish and so Ethan's gonna talk about that I think yeah thanks so as we know if there is one of the drawbacks of aetherium is scaling and that's why we're talking here today about what we've come up with so all those significant improvements have been made across the network our specific use case dummies that's going to be large spikes in traffic especially at the on sale period the theorem can currently handle 15 transactions per second meaning that even if we had the entire network to use we wouldn't be able to properly deliver thousands of tickets for a large event in a timely manner as illustrated here typical sales occur when the event goes on sale so we have this enormous spike directly at the outset and then things tend to level out obviously aetherium is just trundling along with the steady 15 transactions per second so it's not completely ideal for this so we really needed a way to process this huge spike and to be able to deal specifically with transactions related to tickets rather than anything else related to events so tickets with this providing this this enormous thing that we have to deal with so we had to find a specific scaling solution for for those transactions yes as Ethan just mentioned we basically had just a massive bottleneck in the system in the initial ticket sale period so we needed a decentralized solution in order to basically batch a loaded tickets and put them all on once so basically I guess you've come across some local trees is a pretty good solution for that so basically we have kind of like a layer to proof of stake system so any validator would come and lock up a certain amount of our token then they would get access to the layer two and then basically they can process transactions coming in for ticket sales and then validate anything that would have been validates on a smart contracts such that is coming from someone that has permission to sell a ticket and they have signed that the person they've signed they the buyer and it basically that all the signatures check out which will be done normally on the main net so then it just basically bundles up those into a local tree and then simply reports it to the main net and so basically is it's basically as simple as it can be for its use case so one Merkel leaf is just representing one ticket so it's literally just what events it for who owns the ticket and then any relevant signatures so really what we found was the problem with making the scaling solution is we were trying to create the EVM again at a point and realized in order to get something that actually works in the short-term we needed to make it as simple as possible however it does still comply with all the industry requirements we had before like anyone can see that they have a ticket for this event because from these Merkel trees we can build up a state of who is going to what event and it's still completely open when the local trees are published and and then just to kind of up the decentralization since we do have like a smaller proof of stake pool that is more prone to attacks and bad actors and downtime so we kind of have the backup of the etherium Manor whereby any check that is done in the validation step is challengeable on the main net so you can say look I found a ticket here it's on this merkel route here's the Merkel proof for it and it wasn't signed by someone is able to sell tickets for this event it's kind of a drastic measure because it could potentially like invalidate the whole route but yeah it's just kind of like a backup in case we have the problems for example if we got 51% attacked or whatever so how far can we take this so basically since our local trees are pretty simple and we just batch them up we could potentially put three billion in one transaction three billion tickets it's not really viable because the validation would take absolutely forever and also I'm not sure three billion people all want a ticket at once so kind of our peak activity will be when something like Glastonbury goes on sale and we need to sell 30,000 tickets in a few minutes and and I think this is actually achievable with this system we think you can put from preliminary tests running on an average computer you could validate and create a local tree for several thousands of tickets in about a minute so that easily fulfills the industry requirements while keeping it decentralized yeah so where are we now we've built a cloud solution with a single validator running on Ruby as a proof of concept for this encapsulating the entire solution and we have a public API gateway for the cloud solution to abstract away all of the complexity if a ticketing company were to come along and try and integrate with our systems and didn't want to roll their own obviously another key focus over the last six months for us is building a set of SDKs for these external parties so we can get people up and running with their ticket wallet app the the admin side of things for the event owner to be able to create compatible events and tickets using the protocol yeah just trying to simplify things a little bit yeah so just for the future obviously our next step will be to go live on the main there and allow anyone to become a validator on the proof of stake chain and start summing transactions sent by event owners and people like Ticketmaster hopefully I wasn't I was gonna gloss over this a bit but actually we have time so I'll talk about so at the moment we're exploring ZK snarks basically because the industry rains and concerns about the onboarding process so basically the ideal transaction is that someone pays on chain for a ticket and then the less ideal one is that it's somebody that is an issue of a ticket sirens the public key of the ticket buyer and submits that's in the chain however what if that binder doesn't even have a public key yet what if they bought a ticket of Ticketmaster Cody UK like a week ago and then they suddenly decide they want to put this event on the blockchain and so basically the industry said well what if we can give them some sort of secrets and then they can reveal that at the door rather than having their public key which they don't have at the point of purchasing a ticket and it's not very decentralized so basically what we can do is we can use zero knowledge proof to prove that you know that secrets and then sign the hash secrets as the primary so therefore you can see even though you don't know what's going to get you into the door that you will be able to get into the door so it solves the problem with that and then the last one is obviously to get real people using it yes so that's that's us for today if you want to keep up to date with the project just check out any of our socials here type in adventists and your finest and yeah and if you want to come and grab us for any questions anything we can elaborate on we're happy to yeah thanks for sticking around Cheers yeah does anyone have any questions cool well I think that's the end of the day so I guess go and enjoy your evening I think there's still talks going on elsewhere but thank you for coming