ZKPodcast: Findora with Ben Fisch and Benedikt Bunz

Transcript

welcome to xero knowledge a podcast where we talk about the latest in zero knowledge research and the decentralized web the show is hosted by me anna and me frederick i am super excited for today's episode with benedict and ben we're going to be talking about fendora and all of the work that they've been doing on that project but before we start in on this i want to just give a quick aside um i want to check in with frederick who's here today frederick has not been on the show for about like three weeks and i i feel like our audience is probably very curious

as to what's going on yeah i mean it's a it's a good mix of stuff it makes a work in life [Music] but obviously a lot of work yeah no i mean we kicked off the polka dot launch process which is a big thing and takes a lot of coordination efforts it's a very long elaborate process which is interesting but it's all green light so far it's going pretty well and we are very cautious in how we roll this and we want everything to sort of go well for lack of a better definition uh but you know we started super conservatively

like it's a proof of authority network just making sure that the consensus algorithm doesn't have fundamental bugs that there's liveness on the chain etc then i open it up to a broad nominator validator set with people being able to nominate etc scale that up to 200 validators that's running perfectly fine so that's all you know green lights really good good engagement from the community and people who are trying to do stuff on the network so far next step is uh enabling governance and removing this uh pseudo module that can sort of this is the last bit of fail-safe mechanism that we have uh and uh beyond that you know it's it's

decentralized okay so that's uh that's a cool thing that's and this is a project this is a long it's been a long road yeah i mean the project itself is three years yeah yeah but it's definitely an exciting time just the launch project is a long road but uh cool yeah now it's good it's good i mean we get to now kick off and start the real work of trying to build a community and trying to build out actually useful things things that you can do with this just having the infrastructure doesn't actually do much unless you can do something on top of that infrastructure so yeah starting to look at the use cases which is

which is fun i'm super curious now that polka dots out there or almost fully out there um i'm really curious to see how zero knowledge proofs and the privacy concepts that we've been talking about on this podcast make their way into it and i'm gonna hopefully help a little bit with the zk validator that is a validator working on validating on polka dot so yeah it's going to be interesting because we might even see a little bit more blending from this podcast of those two projects as time goes on yeah hopefully i mean i think and maybe something that listeners don't really know or or have insight into is like this for me is not a work project right like this is something that i do outside of work so

that's maybe why it's also strange for people to like how can he be busy with work like this probably isn't this work but no like to me it's not me this is something else yeah well i'm glad that you're back for this episode and i think we'll continue over the summer to have you on but maybe we're gonna also continue to have a few guest hosts so that you can focus on getting this out fully i did want to let the audience know that our friend alexandra had suggested doing an ama with us in the near future so this would be something like asking questions from you our listeners that maybe we can do a bit of research on and answer so if you're interested in that you should head over to a brand new

subreddit that i just created and has very few followers zk podcast uh very few subscribers but i think over there is where we're going to be collecting the questions and i'll definitely be pinging you all over the next few weeks about that so yeah hopefully we get to hear a little bit more from you all right now i think we should move on to today's episode thank you benedict and ben for patiently listening through this intro welcome to the show again to both of you actually thank you it's great to be back yeah thanks for having us cool so benedict you were on the show i think almost two years ago talking about bulletproofs

i don't know if you remember that day it was 38 degrees i don't know what that is in fahrenheit but it was incredibly hot in berlin and we were all in a studio talking about bulletproofs oh my god when i didn't my definitely simply at times you know like uh the world was still mostly whole and uh together but um no i i very much uh remember that that was cool but it's been a long time since then and ben you were on last year and for that episode we actually talked about accumulators so a very specific topic i kind of want to put the question i mean in each of those episodes you did introduce yourselves and gave a

little bit about your backgrounds we'll put the links to those in the show notes if anyone wants to hear more about you know what we had talked about before but i think maybe as a kickoff here what have you been up to since then what's new maybe let's start with benedict cuz it's been longer for you yeah i mean uh you know it's been a lot of things that have been new have been been working with uh ben and being productive and putting out some new cryptography tools and um so part of that is uh we developed a new kind of zero knowledge proof called supersonic or which uses kind of this tool called darks that one

of the key upsides of that is that it's a it's a zero knowledge proof again that doesn't have a trusted setup like bulletproofs but also has kind of features like snark where snarks where the verification is is much much faster than uh you know the the size of the thing that you're actually trying to prove so this has been work with uh ben and alan panyak so that's been very exciting and then um you know we've had some other works you know for example uh recently there there sean and others have put out this this amazing work of halo so i've been working with uh alessandra keza and uh pratush and nick spooner

and from berkeley and we've been working on kind of formalizing that and generalizing the approach that they have there which is a really genius insight and trying to generalize this to more tools and um so that's been taking up some of my time and then obviously you know the what we're going to talk about today kind of the work on fendora that's amazing i mean it sounds like so much of your work pretty much everyone you just listed has been on the podcast in the last like eight months or on the study club i mean it's just so it's so cool to hear that connection point too like for you guys from the stanford group to kind of like also be working on the stuff with the ecc and the people at berkeley this just sounds really neat

yeah i mean i think that you know i think it also speaks to the the high quality of your podcast right like i think you just have really a really broad and cool set of guests and you know it's it's it's an honor to be working with some of them and also you know there's a lot of like even if you don't work directly with them you know the community feeds off each other right someone does an improvement in in one area and then other people get to use it and build something new with it by plugging new things together so that's one of the great things about the academic community in general and i think especially in the cryptography community they were doing a pretty decent job at like collaborating taking other people's

ideas and proving them and uh yeah so that's why kind of everybody knows each other and like i think podcasts like yours are really important for this for for you know spreading the ideas and getting people to know getting you know these ideas out there and and yeah so i think that's really important something we've said on on several episodes in the recent past is how like if you even look back like six months or a year it's it's crazy how much has happened for you who's like knee deep into everything does it feel like that to you as well if you look back just like the crazy speed that things are moving or is this normal yeah i think uh i mean i

certainly think so you know um and i think that's you know part of it is it's just more smart people from different areas getting involved like you know not just academics more practitioners sort of you know and also as things get deployed new issues arise and so which open new interesting questions which then lead to new interesting answers right before you know if things are mostly theoretical and never actually deploy then you know everything seems to work fine but then once you actually try to deploy them then you realize oh okay this this kind of small thing that we didn't even think about it is actually now a huge thing and we need to come up with

sort of a whole completely different new plan to to resolve this and this then maybe leads or ideally leads to a new wave of innovation so i think you know all of these things are definitely correlated and connected you know the increased application of these tools leads to increased attention leads to increased new development of them leads to increased applications so it's right now you know and let's hope this continues we're sort of in a positively reinforcing kind of cycle i think cool what about you ben what have you been up to well since i've last been on the show um many many things of course fendora we've ramped up

significantly probably since we last talked on this show we have a team of um already 15 engineers and we're heading towards a launch of our our test net so that's been taking up a lot of my focus as cto and of course i've been continuing my research mostly focusing on authenticated data structures and zero knowledge proofs as benedict mentioned last summer we released a paper on supersonic or dark which is a major development in trustless zero knowledge proofs and we've been continuing to improve that

since we released that paper in addition i've been working on other general techniques and improvements to polynomial commitment schemes which is a major tool that underlies many of the modern constructions of uh zero knowledge um and verifiable computation systems i wonder did you did you ever see the like justin drake's kind of breakdown of polynomial commitments did you ever get a chance to catch that there's been a number i don't know if i remember seeing justin's nah it was a study club it's on youtube but it's becoming as i understand it's just becoming more formalized like that entire space is like they're starting to see like it's broken down into

into basically more comprehensible structures or something yeah like well one depictions maybe right well one thing that we tried to make clear in our paper on supersonic was a holistic overview of the systems that use polynomial commitments to break it into to separate it into into modular components so there's an information theoretic component as it's called and then there's a polynomial commitment compiler and you can mix and match these things so many of the systems you've heard of marlin sonic planck starks etc they all have a underlying you know information

theoretic backbone that can then be compiled with any polynomial commitment scheme and and that gives you many different combinations of of constructions that have that inherit the properties of each cool you're both phd students at stanford in dan binez group still right that's right how long are you like it's awesome but like are you are you graduating soon i'm just kind of wondering how long i get to call you part of dan bonay's research group to be determined is it so good that you don't want to leave what's up that's not an inaccurate statement i mean that's certainly part of it right

it's it's uh you know it's an it's we have an amazing group you know i think we have a we have an we have an amazing group and and there's a lot of i mean can obviously it's amazing but there's also you know a lot of other great students in in that group and it's um it's a cool uh scene to be around and uh you know i think um both uh ben and i are enjoying it and you know at some point you know i think both of us want to finish but um it's no rush basically yeah not necessarily a time pressure and uh no no no russia i mean it's i think if

you if you enjoy what you're doing and you get you're still productive then you don't necessarily have to rush it it's a very good environment to be in and um there's a lot of interaction and collaboration with with outside entities um and while benedict and i were part of the group we also founded fendora so as benedict said we'll see about the future but it's a comfortable place to be i'm curious every time we sort of check in with the group in general like anyone from the group or see stuff there there's always something new i'm curious about in general in dan's research group like what are the major topics that are

being researched essentially i think everyone's working on something slightly different dan's group covers many topics benedict and i work on zero knowledge proof systems and authenticated data structures for the most part as well as systems that are related to those cryptographic tools other people in the group also work on on on similar topics but but others work on things like adversarial machine learning florian works on that some people work on private information retrieval some people work on you know post signatures from isogenes on elliptic curves

people work on diverse topics who's doing the isogeny stuff dima dimakogan a very excellent uh you know phd i think you know like things are closely tied together i think it's a good moment to actually dig into fendora one of the reasons that i reached out to you ben just recently was that somebody had actually asked us to do an episode on fendor to find out a little bit more about what this project really is i think maybe as a starting point where does fendora come from did you found it was it a project that existed before you joined where did it start no i founded it and of course it's difficult to trace the

true genesis of any company or project but we formally founded the project and i was the first technical member back in summer of 2018. who who are the other founders who who who is the group so i started it after meeting two people in particular one was lily chao who was a co-founder but also a seed investor and john powers who is the former ceo of stanford management company um he used to manage the stanford endowment in fact during the recession and uh tough job he did a good job of it yeah and uh shortly after brought in benedict and charles liu

charles was a phd student actually in dan's group but um left to uh take the full-time role of ceo at fondura uh then correct me if i'm wrong but you know part of the initial momentum and kind of the driving idea of fendora was that you know there were we had really you know someone like john and really these are experts in finance and deep in the world of finance and they just saw problems or or challenges in in the world of finance and then and he brought us in kind of had the expertise to see you know how blockchain ledger tools your knowledge

proofs could sort of address some of these key key issues in the world of finance with uh you know very smart and advanced technologies and kind of this this uh match of of a problem in the solution like a a real world problem and the technical solution is kind of the founding spark i would say of fendora and then kind of still the driving motivation of it cool my my next question was actually going to be around that that topic of was the company founded so maybe i'm jumping the gun a little bit but there's something that is uh findora ledger which we'll get to but was the company founded with that

mission from the start like we're going to build a blockchain or was it founded from you know we have these problems that we know exist in finance and we want to find some solution but you weren't married to the idea of this ledger so thanks for the question i think the founding of of the company was really about bringing together people with diverse experiences both on you know the problem space and finance and on cryptography and blockchain related technologies i don't think that when we started out we had in mind we're specifically going to build a blockchain or we're going to solve exactly this problem in finance you know i i've recognized that the

technology does have does have um can be transformative for the financial space and financial technology in general is uh is due for makeover in many ways and i know that that you know good projects come out of collaboration of people with diverse experiences and knowledge that they can bring to the game like i think we should probably like find out what is findora what is fendora today is it a blockchain like is it a software company what what is it right well it's a little bit of both so yeah we do have a a technology development company and we also have a fendora foundation the technology development company is

developing a software system it's a multi-purpose transactional system that does use many of the same underlying elements of blockchain so you could call it a blockchain syst or blockchain based system it's multi-purpose it can be used for issuing assets of any nature including cryptocurrency so it can be used as the as the backbone for a cryptocurrency or any digital asset system you know it can be deployed in a variety of operational configurations with different types of consensus protocols there's no one-size-fits-all solution for every use case therefore we from the from the get-go we're aiming to make things

flexible and our main focus and product differentiation is privacy which is something that we are experts on and um and and we thought that you know we could build a blockchain backbone system that just does the integration of privacy and transparency very well so it has all the same properties of you know public accessibility and auditability of of other blockchain based transactional systems but also retains privacy to the greatest extent is fendora a protocol though like is it a is it a protocol or is it a software or is it a company fendora foundation is going to operate a deployment of the fendora system

and it will be just like other public services like ethereum or bitcoin or other blockchains the technology development company however is is developing the underlying system that will be used and run by the fendora foundation as a public service but is also applying it to other problems as well for example we have a partnership with tencent cloud and we plan to run a version of the system inside tencent cloud for different use cases than one might use the public ledger for right and and to your question of whether it's a software or a protocol so very similar i think to to other things you know like ethereum or bitcoin right it's a book right you know

like every i think the software kind of defines a protocol so there's a in in that way yes it's both a protocol can define a protocol yeah i think i think this distinction between softwares and protocols has only become a discussion in the in the in the blockchain space which is uh which is an interesting space but i think you know classically software companies have protocols involved in their systems so i would say it's a system and we're going to the foundation is going to run this system as a public service but we may use it for other purposes too and i i think the the distinction becomes important when there are

multiple implementations right i mean parodies history is an example of where where we did not define a protocol but we did define a software right and um i mean taking an example outside of blockchain space like ssl is a protocol right you can't say like there's this company that makes this piece of software and that's designed right that's a good point um yeah but i think in these cases like i think we see um polka dot is still the same today right where it's both the software and the protocol i mean that there aren't multiple implementations so it's not that useful too right talk about extinguishing and i guess usually that's how things start out and then maybe later on uh multiple important but i think you know i want to

highlight one thing that that ben said um sort of as the key differentiator it's uh he was saying you know it's focused on privacy and it's it's important that you know there's other protocols like zcash or monero that are focused on privacy but i think one key differentiator is that we want to have as ben was saying kind of both the privacy and the transparency so that you can still you know even though you have a certain level of privacy you can still make sure that for example you know this token you know say there's a token running on the platform and you can say this can only be transferred between

citizens of the european union and uh you know the rule the the the ledger can enforce these kind of rules much more complicated rules where you know you have kind of selective disclosure only you know very selective information only the minimal information is revealed and everything else remains private so it's really a more nuanced and balanced approach to privacy where you can exactly choose how much you want to and need to reveal that's actually that selective disclosure concept which i did learn from you ben like i guess last year when you were talking about fendora and what it was doing

i've i've mentioned it a bunch of times on the podcast this this idea that like using zero knowledge proof systems potentially along with other systems you have this ability to reveal certain information and keep other maybe sensitive information private yeah so i think right like people think have sometimes almost the misconception you know when when when you think about privacy you think about you know wanting to hide everything about you and you know your some political dissident that has you know some very good motivations for trying to be as anonymous and as private as you possibly want to be but you know i think it's it's important to realize that in for a lot of use cases uh this is not

exactly what you want or you know say a very simple example that i love to give is that you know one company paying its suppliers may be okay with publicly revealing who their suppliers are or not maybe they want to hide that as well and but they definitely wouldn't be okay with you know showing to their competitors you know what price they're paying their suppliers for you know whatever good they're getting so you want to definitely hide you know the amounts that you're paying or for example you know my my salary i might want to you know not have that be public on the blockchain while i'm okay with you know people knowing who i'm getting my salary from or potentially the tax authorities being

able to or the tax properly so yeah and you want you know and companies want to follow regulations and rules right and and they want you know maybe a regulator to be able to exactly as you say like a tax authority to see that yes i've paid the right amount of taxes but they still don't you know want some level of uh privacy towards the outside world so i think this in the real world you know we we really in the real world uh we really have a need for often more nuanced levels of privacy and this is part of the thing that we're trying to address is to be able to enable people to have these you know like uh use these nuanced levels of of privacy and the

selective disclosure but it is that your let's let's take the example of only being able to transfer within you you're disclosing that i am an eu citizen and that's then public to the world it's not that there is like a zero knowledge circuit that guarantees that only these types of transfers can happen actually not so uh the way that it works in fendora is the issuer of an asset that can only be transferred within the eu would place a policy on the asset that can be confidential and that puts the guarantee that the the users who are authorized to uh to transact that asset um have to have eu credentials but

that's not visible publicly to the to the rest of the system that's cool and it it sounds i actually want to dig into this to like the client and the structure here a little bit i mean this sounds like something akin to smart contracts would you say that fendora has smart contracts yes we do have smart contracts placing policies on assets is a basic kind of example of a smart contract and we tend to focus on on policies on assets um but we do have other uh you know types of self-executing contracts that look more like what you would normally

associate with ethereum smart contracts so is there like um a virtual machine that that ships with andorra of some kind or is this are these contracts that you sort of build into the client or into the runtime in some way you know we do have a domain specific language so you could say that you can you can view the fendora system as a certain version of a virtual machine but it's not running a language like solidity we have our own domain specific language for for writing uh policies and um and setting up contracts that is built for predictability and static analysis so it's not

as comprehensive as solidity but we think it covers most of the functionality you would want what's it's what's it's similar to are there any existing projects that you would put kind of in a similar category in terms of what like the actual like how it operates under the hood i would say so i mean i would say that um we overlap with projects that have built in zero knowledge on top of ethereum right there are ethereum smart contracts that run zero knowledge proofs i know of a project called dusk that started around a similar time as as we did and they seem to be doing something similar which i'm not surprised about i

think that you know this is uh an exciting uh application space and so it's um natural that there will be multiple projects working on similar things and and we'll see where that goes can fendora be used with existing blockchains so it's not built to be used with existing blockchains it's also not really clear how to specify what we mean by an existing blockchain the the best way probably would be to to look at the the consensus protocol which is the operational system so if you know if there's an existing network that is running a consensus protocol

that could be adapted to fendora's you know consensus protocol interface then they could in theory run you know the fendura system so they could run the fendora validators using the existing consensus protocol i guess i i guess i'm trying to figure out if it can inter-operate or if it is like if it could sit on top like a layer two or if it could well i'm i'm thinking of one of these like kind of interoperable systems like polka dot or cosmos so so first of all i think that with a system like polka dot since polka dot is written in a more modular way also a system like tendermint you know there's a consensus protocol that is in in

intentionally written to be interoperable with other systems so so we could definitely in fact we already have a version of our system that is compatible with the tendermint consensus protocol and we could likely make one that's compatible with polka dot interoperability comes from systems speaking the the same language so usually you have to put some effort into um hooking the two systems together and it's and it's a matter of how easy that process is but i mean i think if the very concrete question if you know if is vendor in ethereum smart contract no it is not and you know one of the we sometimes get asked like you know why didn't you try to build the system as say an ethereum smart contract and

part of the i mean it's it's it's a multi-layered answer but part of the answer is that you know there's been a lot of work and making zero knowledge groups uh more and more performant but you know we really want to you know we want to be able to handle real-world systems and we want to be able to handle many many transactions and i think to really squeeze out sort of the the latest uh you know optimizations and have the most flexibility in our system it's just a lot more feasible to to do that as kind of more of a base layer uh protocol instead of trying to work within the constraints of you know say

the ethereum virtual machine and especially the resource com resource constraints there i'm curious though like you the the contracts is some sort of decel i wonder if it's an embedded dsl and i'm curious how that dsl translates to machine code because i like give me the the run through of how that works so it probably would be best if you want to know the the guts of the dsl to talk to um to talk to joe from our team who's the main guy who's been working on the dsl i oversee his work but benedict and i are not programming language experts we work more in cryptography but you know at the highest level the

i mean fedora ships with the dsl and also basically the the dsl interpreter um so that's that's embedded in the system we're not compiling to machine code the one thing that we do want to do is is and this was one of the design goals of the dsl is to be able to compile to circuits yeah that's what allows us to take uh dsl policies and make them confidential in combination with our you know zero knowledge uh compilers yeah makes sense it's almost a dsl for writing circuits rather than that's right traditional smart contracts and then you have some interpreter that that takes that dsl in and uh that's

right exactly here's the circuits right well yeah so i guess in some ways the pipeline is dsl to circuit to then zero knowledge proof system yeah makes sense and what like you you mentioned there's plugable consensus which is interesting and i want to get back to a point on that and then you you have the foundation operating some some public network what consensus algorithm does the public network operate on so our test net is running on tendermint consensus and the public network which we haven't released yet we're still um juggling decisions there so there's no formal decision that that we've you know announced in terms of exactly the consensus protocol that

will that will run um i think it's a it's a difficult decision um to make in general but so we're trying to handle all the constraints and and make an informed decision and i mean i think that like you know we've talked in the beginning about the the sort of the improvements and kind of the zero knowledge space i think that very similarly in the consensus space has been yeah a similar kind of circle of improvements and and new developments where people really now look at problems that come up in practice when trying to deploy these consensus protocols and come up with exciting news at new ideas so this is something that we're closely monitoring

in our white paper which we um which we which we released last year our updated white paper we do discuss um in depth our thoughts and perspectives and where we are in terms of you know the current options we're considering in terms of consensus and that takes a blend of techniques also suggests some minor modifications but we're not we have not committed to a specific consensus protocol yet the thing i wanted to get back to on on the topic of pluggable consensus is from the idea of of having privacy or zero knowledge proofs or some sort of you know from this initial

spawn of idea to having a blockchain client with plugable consensus and networking and all the other that needs to happen is a very long step right um why did you go down that path i think it's an admirable path to go down but you know you look around the space and so many projects are like oh we just forked bitcoin and we forked ethereum or we did this thing and that thing to like shortcut the route it writes off a lot of potential applications um when you do that and some of the applications we were you know thinking about from the very beginning uh really don't require a consensus at all so two in particular would be a cloud

operating an instance of the fendora system which would allow for confidential transaction processing in the cloud so banks have been starting a transition from their legacy systems to the cloud for a while and one of the primary concerns is security and compliance you know famously capital one was running their transaction system in aws and uh and got hacked now of course we you know debate the details of of whether it was aws fault or their fault but the simple reality is that if you don't keep data in the cloud then there's less risk of if the cloud is hacked then the data will leak because it's not storing data in the first place so that's part of our reason of

partnering with tencent is to offer this service to banks to do transaction processing on their behalf without receiving their data another example would be to take traditional payment services digital payments like wechat and also another reason for partnering with tencent and venmo and paypal which are not running consensus protocols but are also not handling data confidentially and one of the one potential barrier for international adoption of wechat is the fear that you know they could give their data to the chinese government or do something else with it and if these services would use fendora's system as

or integrated into their transaction processing then they could offer confidential accounts to their customers so those are two examples that have nothing to do with consensus which is why we didn't decide to just fork bitcoin and you know put out another very blockchain specific uh you know decentralized system fedora foundation is is doing that and will pick a particular consensus protocol not not nakamoto consensus but the the idea of that is to be a public service like other blockchain systems and one of the value propositions is that if we get a lot of other enterprises or businesses using the fendora software system in other application scenarios then those will

much more easily be interoperable with the public service that mindoro foundation runs i think you know this is the one of the i guess maybe key realizations or key advantages is that you know the the same kind of transaction technology that is useful for you know a very close system or you know a system where you have one like kind of basically used as a database can then also be used as uh you know a very open system you know that like kind of a permissionless system and uh that's one of the you know that was one of our huge motivations for for kind of trying to make the consensus as modular

as possible because we're envisioning very different use cases but it turns out even though these use cases are so different like the underlying transaction system is kind of the same right it's really you know pluggable consensus really means we're looking at these things modularly there's the consensus part and then there's the transaction part and ideally you can swap them take one you know of each or put them together in different accommodations that makes me think of what you really mean with plugable consensus because it sounds almost like it's not just plugable consensus but pluggable networking and pluggable transaction pooling pluggable a bunch of other things that are sort of

normally key to like a public blockchain and that you consider the fendora system to almost almost just be the transaction processing system like that if we've considered a black box that finder is the input is a transaction and the output is like the modified state well that's certainly the the differentiating piece of software that we've worked on but i don't think this is such a different it may be a different trend than what's in the the blockchain space but i don't think it's so different from the way the software industry has worked where you know a company would develop a new type of database system and still run a fault tolerance maybe paxos or something else

but they would build their differentiating product which is some kind of nuanced transaction processing system and then use standard solutions for the networking and the and the consensus i i don't think it's uh well it it's to some degree uncommon in the blockchain space but not entirely that's exactly how we we substitute to separate out these two to fundamentally different aspects where the transaction processing what we call a runtime is one aspect and the other aspect is like the low level networking and things that you should really shouldn't have to care about right um but but it brings me back to this very large step of like building a whole blockchain is a lot of stuff

how do you do that with 15 people like it's a very tall order for 15 people to build all of this well uh we didn't even start with 15 people we started with with fewer than 15 people and we've grown so as as you know with a startup it's a process um you know it takes time to grow the team it takes time to be able to handle the large scope of a project like this but we're progressing and and so um what we're going to release in august is a test net that just runs on the tendermint consensus protocol and you know does a subset of of what we may do in the future but what we have can at least already be used for you know many of the applications that that

do not require a different consensus protocol than the one that we can support already that's still cool it's a an achievement to do that much with that few yeah and i mean part of the answer is you know you have 15 amazing people you know who are really good at their jobs so that really helps i want to go back to the supersonic work that you mentioned earlier because you said that that was somehow related to the work you do at fendora and i'm just curious like where does that live in what you've described because most of what we've just described is sort of like conceptually what fendora solves for businesses right and then a little bit more about like the structure of the blockchain but yeah

where's the supersonic work right that's a great question so the part of what we do you know or you know we said that we are achieving kind of this balance between privacy and transparency and maybe you know maybe to to listeners of this podcast is maybe obvious but you know one of the key tools that you use for that is zero knowledge proofs right instead of saying here are the details of the transactions you know and you can yourself like in bitcoin you see uh input addresses input or in ethereum you see you know like the inputs to the smart contracts and then you can run the contract and see whether it outputs yes is okay or whether it throws an exception

in our system you know you would give a zero knowledge proof the the sender of the transaction creates a zero knowledge proof and attaches that to the transaction and we're using different tools for different kind of zero knowledge groups so for the simplest transactions you know you can use something like bulletproofs where you want to just say hey um you know this very simple transfer of an acid is is valid you know then maybe a bulletproof is good enough but bullproof says one key downside is that if the kind of thing the statement that you're trying to prove gets too complicated then checking the proof gets quite expensive

right so verifying that the proof is valid is gets more and more expensive the the more and more complex the transaction is so for high complexity transactions we need kind of a snark um and ideally you know we would uh sort of not have a trusted setup and so that's where something like supersonic comes in um which is a snark without a trusted setup which we can use to kind of prove these much more complicated transactions you know something that comes out of our domain specific language right that's what we talked about before is you know someone creates a complicated set of rules that need to be

checked in order to verify the transactions and this gets them compiled into the circuit and once the circuit is is very large then you know it makes sense to use a different kind of zero knowledge proof so one you know example is say someone wants to have kind of a an anonymous transaction where like a little bit more z cash style where they don't reveal you know who exactly they are then it it seems like uh sort of that reaches the limits of bulletproofs and you would want to use a different kind of tool like it's interesting because just for like the previous episode that i just did we actually were talking about starks um and that was actually the argument that i understood from

there as well which is like when it's a very complicated if there's a lot of complicated rules underline something in their case a stark might be one stark even though it's bigger and slower might be simpler than many many snarks that you would need to use right and and i mean i think you know that's even you know there's there's kind of different thresholds um you know maybe a a stark might be good in a setting where you want to prove that you know an entire block in in the blockchain is valid or a set of transactions you know sort of for transaction aggregation uh that you know a set of transactions is valid so there's kind of you know there's there's very there's different levels in complexity

there's like simple transaction complex transaction many many complex transactions and based on the different setting you know i think it makes sense to use different tools or you know this is not i don't think we're at a state yet where we have one tool that you know is the best in all settings and and you know i mean i think this is part of the reason why we have uh you know a fairly high density of cryptography expertise in our team is because you know um we need kind of this expertise to decide which tools to use you know in in what case we also use other tools that can be viewed as special cases of zero

knowledge but they're not the generic zero knowledge proof systems like bulletproof supersonic starks planck etc that people talk about so anonymous credential techniques sigma protocols techniques from classical cryptography literature that are more appropriate for specific things and you wouldn't just throw a powerful generic proof system at so the anonymous credentials that ben just mentioned that's kind of this this eu example for example that would be you know where i want to prove to you that i'm you know i have the credential to to you know do this transaction or i'm a

eu citizen you know that would work with this tool you know this cryptographic tool called anonymous credentials so you have someone issuing you a credential like some passport authority some you know sort of outside authority you know checking your password and saying like hey you're a citizen of poland and uh then you can prove like hey i'm within the list of the eu countries and that's why i can receive this asset or something along those lines i just want to kind of go back to what we talked about earlier like do you have like a you have a language you have a domain specific language is that what you called it and like so you're writing like you

basically have designed these systems we've seen the white papers we've seen like you've like mathematically outlined how these different kinds of snark or supersonic or these kind of different these different kinds of zero-knowledge proof systems work and then you implement them using the domain-specific language but i don't exactly understand where they live and i'm sorry if i'm sort of dumb that way so we don't implement our system using the domain specific language the domain specific language is akin to solidity it's something that a user would use to write a policy on an asset or write a smart contract that the

system understands um we've implemented the the backbone of the system in rust and where the zero knowledge proves to live well the validators or the servers that are doing the transaction processing need to be able to run the verification algorithm of the zero knowledge proofs and the clients who submit transactions need to run the prover algorithm to create a proof that becomes attached to the transaction they may use the domain specific language to write a policy in a common understandable language that then gets compiled to a a um a circuit and then further uh you know compiled into a zero knowledge proof

of a statement i i think i understand what you mean but in that case like this like each of these i'm just trying to understand how how one of these i guess contracts would interface with these different kinds of of systems that you have like the the different kinds of zero knowledge proof systems are they all already there they can just tap into them so the validator of the system runs specific zero knowledge proof systems for the ones that we've chosen to use for specific types of transactions so take for example basic confidential transfers the validators would be running a bulletproof verification algorithm but

for more complex policies they would be running a plunge supersonic yeah as well as a supersonic version of planck but would that be like one set of i guess this is this is actually where i'm i'm curious because you talked about like different deployments of the system would it be that one set of validators will run one set one type or could you have one set of validators able to run many well it's a very interesting question that we you know were debating on the engineering side um could you leave it as a configuration parameter what version of the proof systems this the system decides to run so uh we

decided that the validators we would choose what proof systems they recognize and what they run or at least it it right now it's fixed and we could leave it as a configuration parameter in the future so that if you deploy a different version of the system the validators will run one specific proof system for the you know for the built-in transaction types but you're you're right that that we could leave it more of a parameter so that the user could choose what kind of proof system they want to use for a policy if we allow users to choose different types of proof systems then we have to make sure that the consequences of that choice affect only the user and of the other parties who are connected to

this user and not the system as a whole but for now it's simple right we we choose specific things nice that actually that that's really this is you know in a way tied together a lot of what we just talked about so i appreciate you like taking that kind of slightly simplistic question or slightly like i don't even know i don't want to say dumb question but like it's not dumb at all i had clearly like not at followed something thanks for taking that question that actually really helps to clear it up uh is the code open source the code is not open source yet we of course plan to open source a substantial amount of the code eventually but

right now the code is not open source there are a few components that we will open source sooner than others such as uh our implementation and improvements of uh the dark polynomial commitment system hooked up to the planck which we actually called darker and also another side project that has to do with transparent key management and so those will be open sourced you know sooner than sooner than the rest of the system what what made you make that choice to keep it a little bit more closed for now well it it was a discussion among the various people in the company i mean it's uh it's kind of it's very interesting

to to understand the the trade-offs between these two different models of running a company i think that the background of most people is from more traditional software development and the the inclination is to keep things closed source and then you know retain the option of deciding when when and what to release later when needed so maybe since we're near the end of the episode maybe you can just like tell us a couple highlights of what's going on with fendora and what's coming up yeah great so a couple of our major milestones from from uh from the last year was the release of our supersonic system which we which we talked about and that will eventually be open sourced we

closed our first round of funding led by poly chain capital in december 2019 and in just this past month or well in june we announced our partnership with tencent cloud to uh to offer a product that will be hosted in tencent cloud and what's uh upcoming is our release of a test net in august 2020 so that's the the newest upcoming thing and we're excited to have um you know partners and and developers look at that and play around with it and we're really ramping up our our hiring so we're really interested in having you know interested developers come join our project

can people validate on your system we will have a a select set of validators for the test net um but uh if people are interested in participating in you know in in future iterations of our public uh consensus deployment of the system then stay tuned for more information on that and you can find all of the relevant information just on fendora.org and i think that's a great way to reach out to us if someone is interested in being a validator you can put them in in touch with me and we can you know and it's good to know about those people so all right well thank you both for for coming back on the show and for

sharing with us all of the work you've been up to and giving us a little bit of insight into fendora yeah thank you very much thank you so much thanks for having us and to our listeners thanks for listening thanks for [Music] listening