DAPPCON 2024: Data Availability, Speed And Accuracy In A Multichain World - Tim Kernell

Transcript

hi everyone my name is Tim and I'm from The Tell team and I'll be I'm here today to talk about the next generation of the teller Oracle um so first off I'd like to tell a little story about a few years ago when I was with a friend of mine um we were watching the Kentucky Derby which is a big horse race in the United States and neither of us knew much about horse racing at the time so we decided to make things more interesting we both bet $20 on the outcome and so I took the first half of the list of competitors he took the bottom half and in the end I won the bet but my friend didn't have $20 in his

pocket at the time and I figured he would pay me later but that day never came um so we're not friends anymore but anyways a few years years later I got interested in ethereum I thought it was pretty magical how uh you could create these systems of rule enforcement where everyone has to stick to the rules of the game um no one can defect and it seemed pretty incredible that you could create these uh protocols games that anyone in the world can participate in no matter if they're anonymous they're just random strangers on the internet um you can use uh distributed State machines smart

contracts to layer new incentives on top of an existing flawed uh incentive mechanism from The Real World but there's a giant problem with uh chains like ethereum they're they're super limited they only know about their own little deterministic world by default so if you want to create protocols that depend on external data you need to solve a problem you need an Oracle and if you want to uh build incredibly neutral uh trustless protocols using things like ethereum with oracles you

need your Oracle to be credibly neutral and trustless as well so that leads us to the toer Oracle which aims to be trustless um and decentralized and so teller has been live since 2019 it's gone through multiple iterations since then um but it basically Works currently by having a staked set of data reporters which anyone can stake and become a data reporter and anyone can pay a dispute fee to dispute any data and whoever wins the dispute wins the stake plus uh the dispute fee so that creates a a strong incentive to provide good data it

provides an incentive for people to Monitor and validate all the data um and this data is secured optimistically um so that means that it takes a period of time to wait for disputes before data consumers uh can safely use the data so as we the teller team have worked in this Oracle space um we've thought about some ways that the Oracle can be improved um one one item on this wish list is to have fast robust data so there's a certain set of users for whom data

latency is a big issue where their protocol cannot work if the data they have to use has to be 15 minutes old and then on the other hand there's a long tail of users that have very custom Niche data types that they need um so we think an oracle should be able to serve those use cases as well and another point is that it seems we're in the multi-chain world now so another chain is seemingly deployed every week so more chains should not be a bottleneck for an Oracle and finally the Oracle should be able to achieve all of these uh objectives and more without compromising

on decentralization and trustless so that leads to the next generation of teller which is called teller layer it's a an L1 Cosmos SDK chain um and it works by aggregating together many reports from multiple reporters um it does this aggregation on chain it still uses disputes to penalize malicious actors um and then we have this great L1 for aggregating validating all this data then it needs to be useful to users and we get it to those users by doing light client bridging which we'll talk a little bit about um so as we built layer there have been some architectural

questions problems that we faced um one of which is who actually should report this data we have an L1 Cosmos chain so um that follows that we have have a stake set of validators already they already have skin in the game so that's one potential uh set of people that could do the data reporting but a problem with that is that the uh attender validator set is capped and remember we want our Oracle to be able to serve the niche data type the very custom data type so if your say your validator set is 100 uh

validators and some user has a very custom data type that they want you they might not be able to um convince any of those validators to support their custom data type maybe their risky data type um so therefore we chose to split reporting and validating into two separate roles so the validators are concerned with the deterministic objective chain State whereas the reporter role is Con concerned with uh validating creating good external data which is includes a lot more subjectivity and not as much uh determinism and this reporter set is not capped it's boundless so that means that

if some one of the existing Val reporters does not support some users custom data type that user could choose to go stake and become a reporter themselves provide their own data and they gain the security that teller layer provides another question is where do the reporter Stakes come from um they need to have skin in the game so one potential Place those Stakes can come from is by forcing all users to choose between staking to reporters or validators um but we didn't like that solution that would cause some competition between those those two sets of roles um and that would mean that if

someone chooses to stake to validators that the reporter set is less secure an alternative solution would be to uh create another separate second token um but again that seems to probably create some of the similar competition between the two roles um so we opted to use a dual delegation model so validator Stakes can be red delegated to the reporter set which creates some Capital efficiency in the system and this type of reaking probably doesn't have some of the same uh drawbacks as other reaking they're red

delegating within uh a unified system reporters and validators on this chain have have very intertwined interests now on a separate topic we have L client bridging um one of the reasons we chose tender for our new teller upgrade is that tenderman is very like client friendly so tender consensus prioritizes finality over liveness um and that makes it easy for like clients to efficiently reason about determine uh what the chain state is

um and users can still use use that like client method like the base like client method of verifying 2/3 of validators sign a block header and then using merel proofs to find your data within uh the chain state but we took it a step further by creating these Oracle attestations so with each data report all validators sign just the data and some metadata and so then users don't necessarily have to deal with with the Merkle proofs finding the specific Oracle data within the full uh chain state so we think that's cleaner for for users that are trying to bridge data um

but again we don't really care layer doesn't really care how users read the data so users can choose one of these two options they can create their own uh method and getting in the weeds a little bit for those that might be interested uh using Cosmos we have a fairly new uh upgrade from Cosmos or an ability called vote extensions so that allows you to add extra work and Logic for the validator set um and you can do that without directly editing the consensus mechanism itself it's you have this on

the application layer now another problem with the light client bridge is that a like client has to be able to track has to be aware of the validator set um so each time you update the validator set in the bridge contract you're costing gas and so we wanted to limit those gas costs in the bridge contract so we created a threshold that um under which you don't have to update the validator set in the like client on a separate note we created a 5% limit on uh how much the validator set can change within a 12h hour period so

that that slows down the amount of validators Set uh updating it to do in the in the light client bridge and also it has the added benefit that it slows down changes on our chain itself in the validator set to at least uh slow down some particular attacks uh another point is that us having an L1 gives us the ability to um have social consensus as a final back stop of security for our for our whole protocol um so if if the unfortunate situation arises where some

malicious actor takes over 23ds plus um percent of our chain we could always choose to Fork our chain all the good community members good actors can choose to go in the good direction and Slash the Bad actors um so that creates uh the ability to secure more value than even our whole market cap but there's still kind of an open question um in that complete solution where we can do that perfect uh social con uh social consensus recovery forking on our own chain but then once you go over to

the user chains where the light client Bridge exists that doesn't know about which correct Fork to go with um so there's some interesting ideas research out there about how to solve those problems but I think that's outside of the scope of this talk another um question we faced with creating teller layer was how does data finality work so remember we want to create fast data some users depend on um being able to consume some data immediately which doesn't work for

optimistic data and so the way that we've added the ability to create fast data to secure data quickly with teller layer is that we do onchain aggregation of many reports um so we take a median or mode depending on the use case and that also means that there's potentially the whole chain stake uh backing a particular piece of data so we consider that if 2third of the reporter set has contributed to a piece of data that data is considered robust data which can be con consumed immediately without any dispute waiting period so I should point out that all um data

reporting is optional there is no activity leak there's no penalty for failure to report data at any given time and the reason for that is that we as an oracle we're interfacing with the outside world where things are not deterministic they're very subjective uh apis can go down or we find edge cases and definitions that weren't accounted for um so you might argue that maybe in times of high uncertainty no one should report any data and Oracle consumers should handle those cases themselves um continuing with continuing

with the data finality on the opposite side of fast data we still have our um optimistic data which will likely uh cover more custom Niche data types uh these might be just very unpopular or less popular types of data that most people don't have access to um finding the sources for or they just don't have any interest in in supporting this data type it might be more risky data but so we consider that if less than two-thirds of the reporter set contributes to an aggregate report that's considered optimistic data so in

that case users still build in uh a dispute waiting period to achieve probabilistic finality over a period of time if no one disputes a piece of data there that's a strong indicator that the data is good uh so yeah I think I'm going faster live than I did on my own but just to recap teller layer has created some extra capabilities for the teller Oracle so first of all we've achieved fast robust

data we also still uh support very flexible data types people can can uh Define their own data type whatever they want and they can become the reporter themselves for that data type that they want with teller layer more chains is not a bottleneck um so with current teller we're a set of contracts and on each new chain that wants to use us people have to stake on that new chain and that splits our security thin as we split our um our Stakes among each of those chains and then there's also dependency on token Bridges and the

risks that come with each different implementation of those so with teller layer we've concentrated our security on this one L1 where all data is secured created validated and we've done all this while still remaining trustless incredibly neutral and so like to say that everyone in this room is in a unique position to to build amazing new uh protocols with with this great new medium tool of crypto economics State machines um and if you are building a protocol that depends on external data I'd welcome you to check out the teller Oracle as a solution and you can join

the teller Discord to join in on the discussion are there any questions [Applause] um so you mentioned in the case of a two3 attack you can regain consensus on the teller layer by social consensus but Downstream of that the consumers of all the teller oracles will have already kind of been in trouble no so so like I the the time to reach social consensus like how how do you imagine that process like in in like an example yeah

that is that kind of creates a bit of a you might need another waiting period Then if you really want to guard against that um or one of the uh proposals like I mentioned that there's people looking into this problem um one proposal is to implement social recovery at all layers so yeah which is a big ask but that's the only solution that I've thought of so far and I didn't think of it myself but yeah

yeah hello before it gets to that some of the back stops that we have in place it's basically uh the fact that we don't allow more than 5% of the state amount to be trans transferred into the chain and then also more than 5% of the weight of the validators to be changed um any within 12 12 hours so it if somebody was trying to switch or take over the chain that would be one way that we would sort of know in advance um not sure that we could stop it completely but that would be one way that we could start thinking about that and it it would just take a

long time and also to take over 2/3 of the state um trb or the state amounts it's pretty expensive because then you're going to lose it okay thank you any more questions good thank you [Applause]