Hey guys, glad you can make it today. We're just going to wait around for a couple more minutes here for Sylvein to arrive from Kylin. I think he's having a bit of technical difficulties and we'll get started in about five minutes.
All right, I think it's been a bit of a week for expecting chaos. We're still waiting for our guests to accept their speaker invites. So let's just give it a couple more minutes here.
Okay, wonderful. Our guest is able to make it up on stage. Welcome, Sylvan. And welcome, everyone, to Darwinian AMAs. Are you able to hear me?
Yes, I am. Thank you. Perfect. Perfect. All right. Well, I guess we should go and kick this off. Being a few minutes past the time, just to start. No problem. I wonder if you could just introduce yourself before we get into talking a little bit about Kylan.
Yeah, sure. My name is Sid Van Kofniy. I'm a software developer for over 20 years now. I've had a career in many different areas, you know, from aerospace to simulation, to banking, to the arts, music, and graphics.
And I started working in blockchain. I was working as a C++ Python developer at Ditzmjava also all kinds of stuff. And ended up working with blockchain in 2018. So because I was the C++ developer, I hope
I'll turn to this platform called EOS, which is NC++. And from there I started gaining knowledge about blockchain concepts. So I worked on different platforms like EOS, Hyperledger, Ethereum, more lately with substrate.
and even more lately with the Polkadot ecosystem. So that's kind of my path. Oh, very nice. New half experience with the kind of low level of programming languages that we see people with PhDs and visionaries and that having these sort of credentials.
Just all guys. You could probably count me in that category as well because that's what I learned during when I was growing up. So yeah, moving on to Kyle and what's going on with Kyle and
is super duper exciting, especially when it comes to having all the different parachains working together on this kind of federated Oracle project. So I wonder if you could just tell us a little bit more about Kylin. Yeah, okay, so blocked Oracle
systems have different components to them. A lot of them have their issues and I think instead of going out into the wild right away and trying to make things work there, I thought that it would be more appropriate to try
try and explore things by ourselves amongst the parachains. So I submitted the proposal to have all the parachains installed three pallets, one for submitting data to a buffer system, which we'd be residing on the Kylin
chain and one of them to obtain a feed. Now, not everybody needs to have a feed or not everybody needs to want to contribute to the feed to the buffer system. So there will be different needs and everybody has a different type of data.
also that they would like to see. But all in all, the exercise is mainly to discover what extent we can exploit XCM and to how we can resolve issues around charging
for the feeds or paying for the feeds since not everybody is in the same currency and how we can have a common treasury or maybe have a total decentralization by having around Ron Robbins resolution of the buffer. So it is kind of a common good effort.
Nice, nice. It's always great to see projects working together and developing synergies. So I guess with these pallets that are that fair chain teams will install, they'll have access to submit data as well.
as the kind of feed. And I guess there'll be multiple feeds based on the kind of data that's aggregate. Yeah, for now it's only prices. Of course there will be different APIs that can be called and that will be the choice of that will be made at the beginning.
when the feeds are created, but eventually it would be nice to have strings and bytecode for multiple uses that you can just imagine, like cost-trained transaction.
or actually just having a enhanced voting system where strings can be semantically compared and then put through the dispute system which can be modified to
you also host basic vetting of information on a informational level for just justifying or actually determining if it's valid data for
what I'm trying to say is hits for, you know, so the narrative is not hijacked by anyone and there's no resort to things that are called usually as fake news for example.
Nice, nice. So you've been working on this solution for quite a few years now. And we've, I've only heard bits and pieces personally of what you've been doing. And I, I see that it's quite a kind of grand scheme, how you've got all your components and bits and pieces working together. We're just curious.
about your current state of development and what's your, like how close are you getting to actually launching production products? Okay, well, it hasn't been a few years. Actually, it's only been six months for this MVP. So the code is ready for
the MVP on the grander Schema things. Of course, this is the fruition of many years of thinking, especially on the voting side, on the dispute side. So there's
whole strategy, as I mentioned, there's different components to the Oracle system, right? So there has to be, there's the feed, the buffer system, and the reporters, the buffer system, the feed, but there's also a dispute system which is planned.
to be, which has to be of a quality unseen if things are to be resolved in our proper manner. There's such a thing called lazy equilibrium where people are voting, you know, with their heart instead of with their mind and sometimes it's with their wallet. Also,
So this has to be provided in such a system. So it's a very extensive, extensive project. There's a lot of work involved still before a product that can be sent out in the wild. So to have a functional product,
will take, you know, I was predicting, according to, you know, the timeline that I suggested that by the end of Q1, there could be, you know, some timid approach into trying to outsource outside of the Polkadot parrots
chain network. But I think it's more important that things are ironed out within the parachains themselves at first just to get used to the eventualities that can pop up.
Right. So I had no idea that your MVP has only been out for six months now. I could have sworn that we announced a kind of partnership last year between Darwinian and Kyle and you've been. Right. They're warming up the project in the fight some time.
Right, I believe there was, but it wasn't with the same, as you know, it was somebody else that was there at that time. So it was under a different approach, probably, and a different, with different goals.
So of course when I came to Thailand there was a very good foundation for what we wanted to do, but a lot of the components still needed to be in place for it to be called a Oracle
So it depends on the vision you have for when I started out in blockchain, an Oracle system was just anything outside the blockchain that you would retrieve. But as you go further into the concepts of decentralization, you have to make sure that that data is actually useful and
decentralized and truthful. So in that sense, there's an evolution for sure. It's been a few years if you want to put it that way, but for the true sense of what an Oracle is.
It's only been, you know, since I've been there, I think, since I had the chance to explore fully and document and research, you know, all the conditions that would lead an Oracle system to come to be.
Right. Lots of moving pieces and yeah, I guess we've had a couple of the shifts in in our employees along the way. That's right. So it doesn't make sense that that perhaps we're not as aligned as we used to be, but really happy to see the progress.
that Calvin is making these days getting closer towards, especially the common good of funding proposal and something that's going to work for all parakeets and be a great benefit. So you mentioned you're going to be using XCM and I guess these parakeets
are going to be using XM to communicate with Kylin. Is there going to be some kind of a requirement for the change to be EVM or substrate based or are you really not so particular about? Well, the requirements
As of now, the way the code is is that you need a Parachain ID. I've been approached by lots of other projects which haven't obtained a Parachain status that we should be, there should be some actually on the channel, you know,
there's you could ask the developers there to to probably fix this and it would be fixed you know but I think actually can you repeat the question I think I'm gonna get lost here oh no I'm just wondering if you've got if you're if you're gonna face an
particular challenges or whether you have already faced challenges using XEM, of course, UDM, pair chains, other ports. There was one function that was removed at a certain point. It's a blob, the capacity to use a blob.
instead of integer I believe. So that will be probably addressed. But actually the effort of doing this is to test limits of XCM. So we're hoping to have a resolution
of the buffer within two blocks. So that would mean like 24 seconds. It looks like it's going to be doable and that would be actually much faster than other Oracle systems like Chainlink, which is like 120 seconds or so.
something. So I think it's going to be good for everybody. Also, the feed will be available to anyone who uses Polkadot.js. So if anyone trusts the the parachain system, of course, there'll be some mechanisms
for to have a trustless system, but you know at the beginning it probably is not going to be like that. It's going to be relying a lot on the fact that the parachains are part of a consortium or an alliance and that they can be trusted a bit more than
than anything coming out of the Polkadot system. They all have an investment or a stake in the system. So there will be conditions put on the buffer or there could be conditions put on the buffer also to punish outliers, you know, if the values are
exaggerated or if there's ways to detect it, there's going to be a takeover from many contributors to the buffer. So of course, yeah, there's a... Yep.
So the Federation of the kind of parachain alliance that's collectively providing these these different feeds and futures, I guess it'll work a little bit like the parallel multi-sync where a number of different teams hold
the keys? That's one thing that hasn't been put into place yet, but I suggest that would be the proper way to do it, to have a common treasury, and to be able to use that system to do so. It's been brought
up actually on the polka.form already that is one of the things that will have to be done. But what has been done for now is the simple buffer mechanism on one chain with the creation of feeds and the modification of feeds and delete of feeds
and creating a reporter and removing the reporter. So all the basic functionality is there, but for sure there's still a lot more work to be done. Nice. So what are kind of your next steps going forward in the immediate future?
Well, addressing what you just mentioned would be the most pertinent thing to do at this point. Like you mentioned, a multi-sig between all the parachains and having an urgent proper treasury. There's also things that could
be done in parallel. There's other ways to make an Oracle system, especially on the off-chain worker with the use of roll ups or zero-knowledge proofs. So the original intent was to have a tri-
partite buffer system. And what that does is that you need absolutely a fallback. If something's going to go wrong, you have to rely on other values from somewhere. So by having one a decentralized federated parachain oracle and having
Another Oracle system, which would be much faster because it's on the off-chain worker using zero knowledge proofs that would make two. And what I was proposing is also another buffer which would run kind of a lottery for people to be pushing in. Okay, so what we have now is a pull system.
And on the off-chain buffer would also be a pull system. I guess it could be push also, but what we could offer, which would be available to anyone, would be a push system that anybody could call through the
the extrinsics and that you keep on pushing the values and eventually you're part of the buffer through a lottery and you get the percentage of the feed, the price of the feeds that have been calculated.
So that's. Okay, so that's kind of like for a redundant service in addition to the main decentralized service then is it? Yeah, of course. That's one of the conditions that you absolutely need to have a fallback. Okay, so in this case, it's
It's even better than a fallback because it's also a way for people to have a feed much faster. If they want an absolute value that's secure, you know, because it's been average between three buffers from three different manners, you know, they can wait
24 seconds, but the people that live on the edge or daps that live on the edge, you know, could also query this off-chain buffer and could have, you know, perhaps some advantage. But the in essence, having fallback is the main reason.
for this. Definitely. Yeah, redundancy is so important. I'm going to fail over super super duper important. So I wonder if you have so many moving pieces with Kyle and I wonder if there's anything that we're kind of missing.
in terms of general information. And I did invite Agbona, but I don't see him up on stage yet. But I wonder if you can tell us a little bit about perhaps some partnerships that you
looking forward to in particular or any cooperation you've got in mind for the future. Right, so I am speaking with Fala because I was at Sub-0 and I did see their
their Oracle system, which is ingenious, and I plan to look forward into that with them and try to forward the agenda of this parachain Oracle system, even though I might not be as present.
I would like to be, but I'll be there in the channel that I've created for the decentralized Oracle system. I'll try to do as much as I can to suggest the ideas to form something
that is going to be, I think, challenging systems such as Chainlink, having a tripod type buffer system like that is going to be very powerful. So I believe in it and I'm going to be standing by it no matter what happens.
Well, that's really exciting. There's so many synergies going on with with Salah and especially with their fact contracts and them. They bring in the off-chain stuff. So yeah, wow, that's some there's so much down pack from. Also explore.
We have to service a lot of different chains with different needs. This is going to bring me to look at every chain in somewhat, a lot of detail to figure out what their needs are.
chains are using smart contracts. So, you know, using Swanky is going to be definitely up on the priority list of things to do. >> Well, AG, do you have anything to add to the conversation?
Hello everyone, pretty much. In terms of what's working on currently is together partnership. So we have you know, even Chris, like a committee of mostly fraction.
and then currently what's F14 is strategy how can do a bit of this depth on the front of getting like the MBB with this currently on the audit and then probably going to be live very soon so trying to get more part in to utilize this service
So it's going to be like this by direction now, like the reporting and the fee on puts on puts as of each project that will correctly talk to it. So there'll be a number of partnership announcements coming in the coming weeks. So this is something that's extremely excited about and then we're looking
to having this contribution. Definitely, super exciting what's going on with Kylin. And I'm getting to the end of my questions here and I want
I wonder if there's anyone in the audience that would like to ask about anything I've missed or whether either you, AG or Sylvan would like to add anything before we take questions.
Already, I guess I'll take that as an indication. We did a pretty good job with the questions. Dustin, let's get you up here.
Welcome Justin. Nice to see you. Hi, nice to see you again. I miss you at sub zero, but let's see other events. Let's get to see you guys out.
up here. I have a personal appreciation for Kyland and you know, slide in general like you know you have some interesting history in our space so it's nice to see you.
So yeah, the question, we spoke previously. I'm not sure if this is like a question I could ask. Forgive me if I'm not supposed to, but but it was a question about the
What is it the workers per se, I don't have the right terminology forgive me. I'll change workers. Okay, those particular workers, they're appointed. Did you guys touch on that on how they are appointed to be in that position?
Every node has a potential, I'll need to become an off-chain worker. So right now we're soliciting only the parachains off-chain workers. So that's what I was scared of initially is to go right away into using off-chain workers from anywhere. So at this
point, it's only the off-chain workers that are solicited. And in the vision that I had of how things would work is that the off-chain workers would be doing many jobs to actually further the architecture of having a proper
way to manage the feeds. So the whole idea was to have an IPFS layer on these workers. So that would be one of the tasks you could be a reporter, but you could also be a worker to make this IPFS layer where you could
store the NFT so every feed would be stamped as an NFT and you could have a way to have a market to make these feeds gain value because these feeds would have tangible value compared to normal NFTs which are
prone to speculation and the great of full theory. But these NFTs would actually contain real live data that could actually be worth represent the value of a transaction that's ongoing like a cargo ship with a
with goods on it, with being tracked by geolocation, or that would be just an example of the possibilities are endless. So these off-chain workers right now are just we're just exploring with that, you know, with this MVP by asking the the parachains
to go and call all of these APIs, which are created by the feed. So you decide you want to listen to CoinGecko and Coinbase for the price of USDT/BTC. So you submit that as a feed and it propagates to all the chains.
and all the chains will be retrieving that feed through their off-chain workers, sending it to the buffer on the Kylian palette, and then the feed would be available for everyone. Now, that is the basic use case. The ideal use case is that it wouldn't be just Kylian that's resolved
that buffer. The buffer would be going in a round robin fashion and that would be fully decentralized. At the same time, I mean, before we get there, you know, you have to do first things first and just soliciting the off chain workers to do so much work as is done by calling the NAPIs
is a good thing already. It's the first step. Interesting. So you did mention the follow earlier. So would that include those type of workers as well? That's different. The follow worker is what I suggested would have to come
place if there was a tri-partite system, so like a tri-buffer system. So the buffer system, I mean the circular buffer that takes all the data and gets the mean on it is right now in the runtime. So it's in the run
runtime and it's not on the off-chain worker, but the off-chain worker does go and retrieve the data. Now on the FALA system, it's a bit different in the sense that all the work and all the validation is done on the off-chain worker. So it's done with zero knowledge proofs.
I'll have to look more into it. Actually, I'm meeting on Monday with Follow to discuss this further to better understand their architecture. I might be putting my foot in my mouth right now, but from what I understand, it's not the same type of system. It's much more performant.
it's totally on the off-chain worker. So it's not the same type of system at all. Okay. So essentially it could be interoperable. Well, it's complimentary. So complimentary. Yeah. Yeah. Having both is perfect because it's like a fallback, right? And it's
It's the ability to choose actually the intent with the the Kyland product was to have a configurable Oracle system, right? So you could choose where your data comes from and actually you would know where the data comes from. So behind all of this, there need it would need to be like a SLA.
signed with each block. So our service level agreement that you know where the data is coming from and you accept the terms. So you know which APIs were called, you know which algorithms were used, and you accept the terms with every block. So if there is a dispute, it would be less hairy.
Okay, yeah, I love where you guys are going. That's great. Thank you.
Great questions, does thanks. We did have a Kryptonic up here from a, it doesn't look like these guys have signed up any longer. So is there anything else you'd like to add at this point, Sylvan?
Well, I'd like to thank all the parachains that have joined the alliance that I've created. I hope things go forward and I'll do anything so that it does. It's something I believe in and it sounds like it
really good prospect because one of the primitives that is missing in the polka dot ecosystem is the Oracle and it looks like it's going to go. I just hope that we find the
collaboration that we need and that people contribute also so that there's input from all kinds of different minds and it could be a collective effort.
Thank you for having us. It's so nice to see so many projects coming together to do want to help with this federated and decentralized parent crochet and Oracle Alliance.
We're really exciting to see how this is going to move forward. And thank you so much for your time today, Solvane. I know you're here on your own time, so I do appreciate it very much that you took the time out of your day to join us and talk to us about Kylan.
Let me see here. We've got funky with one more question before we re-bought for the day. Sure.
Thank you. Welcome. I'm up to state. Would you like to go ask your question? Thanks, Megan. I just actually first and foremost, thank you so much for everything that you shared, and I'm very interested in
what you guys are trying to accomplish, but I am a non-technical person. So when we talk about off-chain workers, what exactly is that look like? Are you talking about just sort of infrastructure pieces that are like relays, that are sending data, and that sort of thing? The reason I am
And so we just like recently got an RPC node grant from the Treasury, so we're running RPC nodes for the Kusama Relay.
chain, we have a bunch of other validators, co-lators running on different chains. And so just wondering what an off-chain worker is and then if you guys need any help in terms of infrastructure, I'd love to chat. So thanks for that answer in advance and I appreciate all that you shared today.
Cool, that's a good question and funny that you mentioned that but there is a different versions of Offchain workers. Right now there's this thing called ASEX that you can use and is totally detached from the runtime.
And you can probably do much more. I haven't had the chance to explore that avenue, but the off-chain worker is actually Detached from the runtime. I think except for its storage or no, actually it's the reverse. It's still tied to the runtime, but has different
storage. So you can actually, it runs at the end of the block. So at the end, when everything is all the computations are done at the end of the block, there's some computations that are left to do off-chain. So I believe this can be done with the with the faculties of the
of the machine on the storage front. I think there's also the possibilities to reach the HTTPS. So if there's a function for retrieving off-chain stuff, right? So there's a function HTTPS that can call URL in retrieving
that and put that into the storage. So that's the functionality that is considered to be an off-chain worker. Like I said, there's an even more pertinent version of that, which is called ASX, I think, OCE.
x and that will be much more pertinent to what the functionality of the Oracle system will be for running code for certifying with zero knowledge person things like that.
Thank you. I appreciate that.
And we did have a cryptonic, honestly up to the stage, but it looks like maybe his question was answered. All right, so thank you so much everyone for joining us today and thank you, so vain and AG for telling
us more about the Kylin project and really looking forward to seeing how the development progresses and how everyone can come together. Parachene teams can come together and work on this federated alliance.
Thank you all. Bye bye. Hope you all have a wonderful weekend everyone and we'll see you all again next week for a surprise guest. Take everyone. Bye bye.