Session Date/Time: 19 Oct 2026 11:00
[00:01:08] Claire: We'll give everyone a few more minutes to join before we kick off because I think we've only got about seven people. Hi, everyone. Looks like we've got a nice group of 12, so I'll kick off. Oh, Martin, can you hear us? Okay. We've got no Wes today. Bless him. He's had a a clash, so he's unable to attend. So be gentle on me. Quite a packed agenda today. So thank you everyone for your contributions in advance. I will try and keep us to fairly strict timings. So without taking up too much of our time, I'll just quickly whip through the standard IETF note wells. I'll keep peach and swim for about five seconds or ten seconds just to show that you... And, obviously, we all know the process by now, but do reach go on to the ITF if you need to have any more information. These slides are also available on the data tracker as well. Again, the the links to the processes and the code of conduct. So this session is being recorded, but can I have a volunteer for official note taking, please?
[00:04:23] Rafael Belchior: I can do that.
[00:04:24] Claire: Thank you, Peter. That's very kind. And here is our wonderful mailing list. It's been very active recently, so thank you, everyone. So like I said, quite a packed agenda. So I've whipped through point one. Point two is document status and reviews. I've put Hyojin on there. Peter, my apologies for not reaching out to you sooner. Are you in a position to go through the core and the architecture documents?
[00:04:57] Rafael Belchior: That's fine. That's fine.
[00:04:58] Claire: Thank you so much. So we'll do ten minutes total on that. And then Thomas has got quite an important discussion point on the protocol. Rafael's got a a very exciting update on the open source implementation. Denis is gonna go through some of the stage zero registry work, which I think was part of some of the feedback we received. So very well timed. And then a guest today,, who's going to go through the security analysis, which, again, I'm quite looking forward to. So very packed. I'll take no more of your time, and I'll hand over to... Peter, do you mind if I hand over straight to you to go through the core and architecture? Oh, and Rafael's got updates as well. Okay. So between the two of you, take it away.
[00:05:52] Rafael Belchior: Rafael, you wanna take this? Hey. Yes. If I can take the the core draft updates, namely the the the feedback you received, I can go over that and then pass over to you.
[00:06:08] Claire: Thank you.
[00:06:09] Rafael Belchior: Can I share my screen? Can you can you see my screen, the presentation?
[00:06:36] Claire: Apologies. That was me not finding the right button.
[00:06:42] Rafael Belchior: I mean... Ah, right. Got it.
[00:07:13] Claire: I think we may have lost him. Give him a minute to come back.
[00:07:18] Rafael Belchior: My apologies. It seems that my browser crashed. Okay. I've asked the permission again. Thank you so much. Alright. Here it is. Thank you so much for your patience. Alright. So I bring you here some analysis of the feedback we've received from the different from the different IDF areas. But first, I would like to give you a quick overview of where we stand on the current core draft version. So since version 13, which is middle of of June, we've incorporated previous feedback. We've done a couple major improvements or major changes such as moving the media type to set people's JSON and the improvements on the error models. Thank you, Martin, for the the work on that. So we would standardize the error messages to fall RFC ninety four fifty seven. We define a a that we want to use for our messages and several other improvements, typos, maintenance stuff. So since then, we've received feedback from different groups. Thank you so much to, Joe, Kyle, and all the other people who provided feedback. And we received quite a lot of comprehensive feedback that we believe it will help improve the the core drive substantially. So by area, where... When it comes to the security directorate, we've received a number of feedback issues or feedback suggestions that could be grouped into two main groups. First one is the failure modes and the the semantics of termination in our protocol. And I'll go in detail over these these specific group because it's a great source of issues for us to improve. And then different improvements over trust anchor definitions. So how do we do the key certification at the station of gateway of gateways, the binding of some cryptographic primitives that we are using in our protocol, some claims that we provided to the draft but do not elaborate explicitly. So how do we prevent reply tags? How do we prevent double mean? Which we have discussed in detail over the the months and years in this group, but but it's not very, very clear and explicit on the draft. So many of these issues, actually, we just need to rewrite better and be more explicit on the draft. We've seen... We've thought about most things, generally speaking. Then on the general directory... The directorate, we have essentially concerns over the... Over race conditions that might occur in the protocol. This is tightly related to the feedback we've received in the security group. And some more specific definition of our network block type. Right? So we define this. We say that there are three different types of blocks, but then in another section, we say that this is basically an implementation detail, and we have to define which ones we want to support on the first version. Then a major component that requires us to discuss it in this meeting soon. It's the transport discussion. So is HTTP the right substrate for API two communication between gateways? And we can have a great lengthy discussion about this. And, similarly, what was proposed was for us to consider that instead of prescribing a certain transport transport, we can define our protocol as being implemented over JSON and over an abstract transcript. So we we define an abstraction. We define the properties that that such transport needs to provide, and we leave it as an implementation detail for people to choose HTTP, gRPC, etcetera. Then we have INA consideration. So we were asked which registry we want to use to register the set p URLs. We've decided or we are on the way to decide which is the precise URL format, but then we need to decide the registry. Right. And I'll try to be brief and provide some more details on what was the security director feedback about. Quoting the reviewer units, there appears to be national risk condition, and the reviewer describes here a case. This is a true positive. It can happen where one of the gateway crashes or terminates or does network problem and leaves the transfer in an inconsistent state. Right? We have discussed these scenarios. We have identified actually in in the whole protocol where this might happen throughout the years, and we have a dedicated draft to this. It's the crash recovery draft that defines the specific conditions, the specific assumptions that we make on the protocol such that we can avoid such states. Then the review identifies some retry hazards on the semantics of the protocol. So, again, if... What what happens if network is the communication channel is not stable and a gateway lose connection then retries a post several times? What are the replay mechanics? What happens if the message is sent and the the gateway crashes right after? What's the consensus failure if two gateways do not agree? What to do when parties disagree? Because the the network partitions will happen eventually. We cannot have, you know, liveness consistency. And low latency, essentially. So we have to choose what's the the recovery model pretty much. And this is addressed or at least partial address in our crash recovery draft, which we had a reference to in core 11 and later was removed in core 12, which we deem this as future work. So all in all, we have addressed these issues at least partially, but they are in this crash recovery draft that currently is not referred by core. We we need to agree on how to proceed. Well, in conclusion, we will incorporate the feedback on qualification request. We write improvements, type of... That's the most... More straightforward part. Then as high priority items, we need to decide what's the transport layer. What what we do? Do we prescribe one? Do we define the channel properties and work upon that? Similarly to the failure modes, do we refer the crash recovery draft? Do we bring parts of the crash recovery draft to address these these concerns? We will need to decide this group. And last but not least, we will incorporate learnings from implementations as they can guide protocol specification. And that's all. Thank you so much. I'll be open to to questions if we have the time, Claire, please.
[00:16:07] Claire: No. Thank you very much. That was really well put together. I've got no hands showing. Did anyone have anything they wanted to come in on? Thomas has got a question. Yes. Yes.
[00:16:23] Thomas Hardjono: Quick one. So so since the the, and some of the the the the senior folks here who who've been that yet for years, so the crash recovery draft is still under development. Can it be cited in the non normative references section of core? Can... Let me rephrase it. Can an RFC list a... In the non non... Normative parts, you know, references, a... An unfinished draft?
[00:17:02] Rafael Belchior: I don't think so.
[00:17:07] 張一凡: Right?
[00:17:11] Claire: I might be one to take offline normally with the ones that need us on on the IETF standard. So maybe one to take offline.
[00:17:19] Thomas Hardjono: Yeah. Peter, I I kinda thought that was the case, which is why... So this is this is my bad taking it out. But, yeah, let's let's ask again. And and, I mean, worst case scenario, we can cite... So Rafael has published a bunch of papers on this. So those are published and publicly, you know, available. So we can cite those papers in the nonnormative references.
[00:17:44] Rafael Belchior: That one should work, I think. Yeah.
[00:17:50] Claire: Hyojin, over to you. Thank you so much for your patience.
[00:17:55] Hyojin Song: Yeah. I I have a question about the SATP core draft. Regarding the INA registry, I just wonder if we plan to add a specific scheme or URL format directly into the core drift?
[00:18:18] Claire: Sorry. Who was that question directed to?
[00:18:22] Hyojin Song: Rafael or Thomas? Could... Do you hear me? Yes.
[00:18:31] Rafael Belchior: Could you please repeat the question?
[00:18:34] Hyojin Song: Sure. Regarding the IANA registry, I just wonder if we plan to add a specific URL scheme or, yeah, next three. Yes.
[00:18:51] Rafael Belchior: Yes. We... We've discussed what's the what's the scheme for the the URL family we want to register. And there were a few proposals. The latest one, I showed it in my presentation. I'll paste it here on the chat. Of course, we can iterate on it. The idea is that we we define the, you know, ITF, perhaps set p, and then we have different groups depending on the types of messages. So there's a group for the main protocol. There's a group for the errors. That's one of the possible directions we can take. I'll place here the proposal that we have on the chat.
[00:19:36] Martin Gfeller: Okay. This was... We we checked that with all the RFCs discussing about urine registration. These are a few, and they seem to agree that this is the format these such things should provide, or that's where they should register. The one Rafael just posted in the chat.
[00:20:05] Hyojin Song: Okay. So the the description of the URL format is provided, then I'm willing to review or provide some comment on the registration. So I just ask that. Thank you.
[00:20:32] Claire: Okay. Thank you very much, everyone. Hey, Arjin, over to you for an update on the use case. If you could keep it to under five minutes, that would be really, really helpful. Thank you.
[00:20:41] Hyojin Song: Okay. So click on share my screen. K. Do you do you see my screen? Okay. So I have just shared a brief review of the latest comment from other groups. So I just briefly share the comment via my email content. So first one, AD review that has been provided by Andy at June 9, and use case offers have been handed the comments. So most of the comments have been addressed, but when I briefly look at the updated revision of the use cases spec, I found little bit items to be improved. So I have just listed like this. So the major comment of the AD and D specifies that a specific service or system should not be directly described in the use case draft. So... But parts of them has been still exist in the draft, so I have just specified that contest like this. And the others is a little bit minor comments, so please refer to those comments and, yeah, update the draft provided by AD review. So that was the first item. And the second review has been delivered by GenART Group, July, September 24. So the result was ready with issues, so it seems no problem. But there were three minor comments like this, so please just refer to them. And as one of the comments, set p core and set p architect could be referenced as normative ones, not informative ones. So I think it makes sense. So that... That's one of the comments. And regarding the trust model, we have some precondition of the relying party, such as participating network and gateways. So it could be briefly specified on the draft as well. So... Yeah. And the third one is about DAT related claims. So I forgot the point, but, yeah, it might be related with some of decentralized format on some descriptions, so please check this as well.
[00:24:35] Claire: Thank you. Rami, you've had your hand raised very patiently. Did you want to come in?
[00:24:41] Venkatraman Ramakrishna: Yeah. Sure. It's probably better to address each point rather than all of them at at once. So on the on the names, like Netflix and so on, I did remove the names from the sentences, but I redeemed them in the references. Is that... Is it allowed or do I need to remove those as well?
[00:25:03] Hyojin Song: I remember that. Oh, yeah. Okay. Yeah. Makes sense.
[00:25:08] Venkatraman Ramakrishna: Yeah. So, like, if you look at the sentence, there's a sentence talk... Talking about streaming services and then in square brackets is Netflix because that's how the reference is named. If we... If streaming services are understood well enough, I can remove the references there. But... Yeah. Anyway, people can comment on the mailing list if you don't want to... If if nobody has an opinion here. On the second thing, if you go down on the trust model... Yeah. So is the... Yeah. The use case of draft, I think, mentioned a couple of places that we're relying on the trust model. I don't know if I specifically say trust model, but definitely about security considerations. I say that we are relying on the... Whatever has been stated in the architecture draft. Can we do that? Is that sort of a dependency allowed, or do we need to state it again clearly in the use case of draft? Question to the product group.
[00:26:13] Claire: I'm gonna my my opinion is that as we've always said that all three documents need to go together and be read together, that's probably okay. But I would suggest you pop that question in the mailing group for someone like Wes to provide a bit more guidance on.
[00:26:29] Venkatraman Ramakrishna: Got it. Sure. Thanks. And, yeah, I know there's been a lot of activity on the meeting list, but I was on vacation for a while. And then the past week, I've been busy with some work. So I will respond on the... I will carry the conversation there.
[00:26:42] Claire: Thank you.
[00:26:45] Hyojin Song: And the third one is ended by... Provided by ops DIR conclude by Ben, and it specifies the only health issues result. So we need to consider the EPP coordination described in section six. And in my opinion, we could simply add a brief explanation of the application level responsibility for correlating ZFP transaction evidence with EPP outcomes. So then... And Ted has mentioned the EPP related ones, but I think it could be simply handed by adding some of elaborated explanation about it. So, yeah, the third one means means this one, and the last one is about DNS DIR review comment. And I think most of the comments could be comprehended in a simple ways. So... Yeah. So, yep, that's it. And has already replied this email today so that the authors of use cases will handle most of the comments on this email probably by... Before the upcoming in person meeting. Yep. That's it for the use case. Review comments.
[00:28:44] Claire: Thank you. I see no hands raised or questions in the chat. So if everyone is happy, we can move on to the next point on the agenda, which I have cleverly put on a different place, which is Thomas over to you for the HTTP conversation, please.
[00:29:08] Thomas Hardjono: Oh, okay. Thank you, Claire. So so... Go ahead.
[00:29:16] Hyojin Song: I'm sorry. Sorry.
[00:29:18] Thomas Hardjono: Oh, okay. Okay. Yeah. So this is this is just a recap of of a of a question that I think we all know because we've been discussing this on on the mailing list. You know? So is it enough for core... As Rafael was saying, is it enough for core to define a a a protocol in the abstract without stating the transport substrate? So this would allow, SAPI to be... To have a lot of flexibility so that if someone wants to use, gRPC as a tran... Transport, then that's fine. They would have to define, you know, the precise parameters and configurations. That could be a separate short draft. If somebody else wants to use HTTP, they could do the the same. And the more I think about it, since yesterday, the the more it it makes sense, I think, because for those who don't know, the the the use of HTTP, you know, has been there from... In draft courses, I think draft zero zero, just just as a a way to identify transport and identify, behavior. And so that that was, the question. Is it is it okay if if we do... If we just define an abstract protocol without defining the transport substrate? Any any thoughts, any objections, any alternatives?
[00:31:05] Claire: Yes, Martin.
[00:31:06] Martin Gfeller: Yeah. The drawback, of course, is that without the first document, two different implementations cannot say they're compatible because they might map the abstract transport to a particular transport like gRPC or HTTP in a different way. So that that would be the drawback of having to define an abstract transport. And, also, we would have to define quite in some detail what the minimum transport has to provide. So that's an added an added task. We cannot rely on just a description of an actual transport. Transport. I I haven't made my mind of which one... Which route we should go, but I think, Thomas, you think the abstract transport is is best.
[00:32:00] Thomas Hardjono: Could could we could we, you know, you know, just write write some additional text or propose text to define the features capability... The desirable properties of the underlying transport substrate and and, you know, have that text, you know, maybe half a page a page, you know, into... Actually, maybe in... Into both core and architecture, but definitely into core so that whoever's reading core in the future will read this, and it would help them figure out what kind of transport they need to choose. Mhmm. And and also point to the fact, Martin, we will need additional drafts, I think. So if somebody wants to write, you know, okay. I wanna bind this. You know? So you saw this comment about TLS binding. Right? So so if we're using HTTP or using gRPC, the binding is gonna be slightly different. So so, you know, we will need in the future additional drafts, to to make it specific. And and I think looking at, you know, the implementations, I mean, between Rama and Rafael, I think I think you guys can describe the gRPC implementation pretty quickly in a separate draft, for future work, you know, not not not the current deliverables.
[00:33:37] Rafael Belchior: If I can provide my opinion, I think Martin's concern... And please, Martin, confirm. I don't want to put words in your mouth, is on the fact that if we don't mandate a transport, if we keep a transport agnostic, which I think it's a good idea, but not not the whole conversation, then we have... We might have compatibility issues. Right? Because although the messages are defined, we we need to find the messages, right, in which format. Well Mhmm. If the transport is not defined, we don't know. Right? So the the implementations might use different transports, which corresponding to different sets of bytes being transported into Or or one might way.
[00:34:23] Martin Gfeller: Might use HTTP HTTP put instead of post or whatever because we we need... We then would need, as Thomas said, a document describing how the actual transport is... How it maps to the actual transport. So Right. All details.
[00:34:44] Rafael Belchior: Right. I think it's a good idea not to say, well, set p only works with this transport, and you have to implement this. No. Like, we could say, well, these are the properties you need to assure. If you want to use another transport, well, sure enough, perhaps there's... In in the registries in the future with stage zero, gateways can negotiate their own transport and and agree. Right? But we probably need a first mandatory transport to guarantee interoperability between gateway implementations. To guarantee. Right? Not just, yeah, it might work if they use the same. No. We probably need to to define at least one. That's... I don't see another way, but perhaps Yeah. Perhaps there is.
[00:35:32] Martin Gfeller: I would I would agree with that, and that's typically the ITF standards too. It must implement this. It may implement authors, and these are the minimum requirements for the authors. So
[00:35:49] Thomas Hardjono: k. So so thank you, Martin. So so so in addition... So this is for core. In addition to describing the desirable properties of a transport, Rafael and Rama, could we actually add an appendix to core where you describe this is how you do it when you're using gRPC. Because the way I look at it right right now, it seems gRPC is pretty popular. And, I mean, the the blockchains all use some, the layer ones use, like, some version of RPC, most likely gRPC. But what what do you guys think?
[00:36:35] Venkatraman Ramakrishna: Yeah. I mean, it works for a general publication. So we're writing paper, then I would do that. If it... If it's good, fine for an idea of draft, then, yeah, we can do that. It should be easy to write.
[00:36:50] Martin Gfeller: We we could make gRPC and HTTP both an appendix. So appendix one, gRPC, appendix two, HTTP, and then say it's... You have to choose between one of them and both gateways have to support the same. So
[00:37:12] Rafael Belchior: I I I want to know... I would like to know if GRPC is welcomed by the the the different area reviewers or or or group directors because it is not an RFC. Right? GRPC. It's an industry standard. It's not the formal standard.
[00:37:35] Venkatraman Ramakrishna: So so, Rafael, I I think we're discussing, I think, a week ago. I've seen references to, like, JSON RPC and some RFCs. JSON RPC is also an industry standard, not a not a 90 standard. Right? So I think people should not have problem to GRPC as long as we fight it problem. But, yep, others who know better can say.
[00:37:58] Rafael Belchior: Right.
[00:38:03] Martin Gfeller: I think we have to have the opinion of somebody like Wes for that because my my attempt to to get that out of the area director of transport was completely unsuccessful. He said he cannot advise us on that.
[00:38:21] Thomas Hardjono: So so thinking of of, you know, ITF, RFCs citing non ITF document, I mean, the first... One clear example is, like, the RATS working group. The the whole thing is built on the work that the trusted computing group, which is an industry alliance, you know, have been working on for the TPM hardware. Right? So, you know... Well, without TPM hardware, you're not gonna get you're not gonna get rats. So I'm I'm assuming, you know, that's reasonable. Is is the question more specific? Like, can we... Do we need to cite gRPC in the normative section, or could we make it in the non normative? And, Martin, having having appendix a and appendix b would be great, gRPC and HTTP. It's it's going to delay SAPI core, but I think it's the right direction long term because we want we want core to be adopted. You know? So so, yeah, I think I think, Claire, I think this is a this is a Wes and a Claire question. Could we could we do that? Could we, you know, first thing is could we use a protocol gRPC that is not an ETF RFC? I'm I'm tending to say yes. Why not? But it needs confirmation from the, you know, the the Alzheimer's in the ITF. Let's... I don't wanna say old time... People who are who are, like, on the IAB and, you know, people who know this. And then, you know, secondly, is it okay to add appendix a and appendix b to describe how you'd, you know, implement this on on gRPC and appendix b on HTTP?
[00:40:16] Claire: With my non ITF hat on, I would say that that sounds absolutely reasonable, and I don't see why it wouldn't be. But much like yourself, Thomas, I am not a ITF veteran. And this is the sort of area of expertise that Wes would normally bring. So tentatively, would say that that seems perfectly reasonable, but let's let's peg that to Wes for some more official guidance on that.
[00:40:44] Thomas Hardjono: Okay. Thank you, Claire. I I I think that's that's all I have. I wanna give time to the other speakers.
[00:40:55] Claire: Thanks, Thomas. That's... That was really nice and concise. Thank you, and a really good conversation. I would ask if you could pop just that option in an email to the mailing group, and I'll let Wes know to to keep an eye out for it. Was there anything else people wanted to add on this subject? I think we had a really good lively conversation there. Okay. Fab. Rafael, would you kindly take the stand for the open source implementation of SAP, please?
[00:41:29] Rafael Belchior: Yes. Thank you, Claire. Alright. Thank you so much. I appreciate your patience. Things are a bit slow today. I'll present a quick overview of what's implemented in hyperalgic peptide. Reminder, we have two implementations, Rust based implementation, Weaver, and the set the Hermes, which is TypeScript based implementation. I'll describe what we've been doing in the TypeScript implementation with considerations on recent developments on the core draft. So a quick reminder of the architecture of what's currently implemented. We have hyper larger cacti, the big box, then we have a cacti node, which is a wrapper over the set the gateway program. And here we define an API server which implements our API one, which is the client application to gateway communication layer. We implement this with HTTP or HTTPS because it's it's a suitable communication interface between the gateways and their clients. HTTP, you create... You do post, you do gets, you do puts, and you... Based on this interface, which we haven't standardized yet, at least in in a great detail, you can interact with the gateway, initiate transfers, reach state, and so on and so forth. Then we have a component which implements the API two, which is the core of the core draft. And for practical purposes, we have chosen gRPC instead of HTTP or vanilla HTTP because gRPC is based on HTTP two. And the decision... The reasons for this, we can provide a brief overview, but we deemed this protocol more suitable for our communication needs and also considering how gateways might evolve in the future in terms of scalability and performance necessities requirements. So all in all, the current implementation is not set p compliant. It's set p guided, but I I suspect that in the next months, we will do a lot of working alignments. And based on the outcome of this feedback, we'll have a lot of clarity on what to do next. Then we have the API to implementation, which we call the adaptive layer, which allows gateways to call external components. It's... It will be necessary for fully functional implementation. So in hyperlogic, we try to take the the graphs and create a usable product, right, by the industry, by by people who want to experiment with this. So, obviously, we have to make decisions that are out of scope of the set the ITF group. The current implementation. So the core specification prescribes in this moment version 17 h t... HTTPS posts, and the media type is application set p plus JSON. So very reasonable. We we have to discuss the HTTP part, but besides the the media type, that's that seems very reasonable, not very restrictive. Our connect implementation uses gRPC. Actually, it's gRPC web, but we want to migrate this to gRPC. GRPC web because at the time, we wanted to make it SETI compliant, and midway, we discovered that this is probably not the best idea. So we we... For now, it's gRPC web, but we're going to migrate to gRPC. HTTP or HTTPS for MPI is one and three. So why gRPC and not HTTP? Well, according to one of the reviewers, it might be too pathetic, too complex, and might be not the most suitable protocol to... For gateway to gateway communication. In our experience, gRPC has a set of features that align with the feature of gateways. So, for example, bidirectional streaming, imagine you have a long lived transfer. Right? When a gateway is communicating with other gateway, at the very least, it will take, like, half a minute for most blockchains to to confirm a transaction when traffic is very high. But, you know, when we integrate with different infrastructures, these sessions might take hours, days potentially. So we might want to have long lived sessions or transfers, and gRPC provides us that. Also provides the tri semantics out of the box, which is very useful to to help with crash recovery. And then we have multiplexing and other performance optimizations. So the work we have been doing this year, we mostly focused on creating these different... Implementing the different APIs except API tools. So we have API three and API one working. We have support for many distributed ledgers, including hybrid logic, EVM based blockchains, CDM, polygon, layer twos, and so so on and so forth. And currently, we support set p version 13. Right? And what we want to do is after we incorporate feedback from the different areas, we want to update the implementation to reflect the light... The latest version to be fully compliant. Until the end of this year, we are implementing the full support for the crash recovery. We think that we might have to do some tuning to the protocol based on the feedback. After reading the the feedback carefully, I think that we don't need to do many changes. But, certainly, the devil is in the details and the crash recovery protocol, it's, I would say, even more complicated than core. Then we've also implemented some... This is more on the engineering part and practical deployment. So all the tools. Right? So we know that gateways should record logs, and we have that process well defined in the crash recovery draft. So write ahead logs and a mechanism that allows gateways to to synchronize their views when they diverge. And these audit and compliance improvements are essentially simple algorithms that allow to get the relevant logs for a time frame and output them to a client. So you could, with these, understand what's the state of a transfer at any point, which step is the transfer off, and and so forth. Next year, we would like to align the implementation with the with the drafts completely. So that's... This is what I mean by fully compliant. And we are also starting to explore stage zero as it registries, a gateway at station because those things are although currently out of scope for implementation and deployment purposes, they are very important. And work needs to begin on this. So this is one of the directions. Later on the year, we would like to formally model set p. So this conversation has been here for years on modeling the state machine of set p, getting some formal assurances on the properties of the protocol and so on. We never had the time. So, hopefully, next year, we'll be able to do that and start creating and deploying POCs with industry partners. That... That's one direction that could benefit the protocol because the protocol has a lot to learn from the implementation. Of course, the the specification is the source of truth, so to speak. But practical experience with the protocol is always useful. Right. And that's it. The... This project is open source, so anyone can grab the code, see the road map, contribute to the implementation. You are welcome. Just follow the links, and you you can participate on implementation, of course. This is all I had to present. Thank you for your attention, and I'm happy to answer any questions.
[00:51:02] Hyojin Song: Thank you, Hyojin. Yeah. Thank you for sharing the status of implementation. So one question about... Regarding the comparison between HTTP and GRPs. Was there any experiment about load test for verifying each one is better in terms of the protocols?
[00:51:38] Rafael Belchior: Thank you for the question. We have conducted a series of performance experiments over the years on the protocol, namely on the performance of the protocol with and without crash recovery and by parallelizing transfers versus running them sequentially. But we have not... We we have ran those experiments on the gRPC implementation we have and not HTTP. So to answer your question directly, in practice, we don't know if HTTP would be better than gRPC because we didn't run experiments. But theoretically, gRPC is faster.
[00:52:20] Hyojin Song: Okay. I guess the normal case, it seems no big difference between them. But in a specific scenario or use case, the selection of protocols would be important. So I just wonder, yeah, the previous work. Thank you.
[00:52:38] Rafael Belchior: Yes. Yes. Thank you. That... That's absolutely correct. In the small scale experiments we we are we are doing and we have been conducting, my my hunch is that there wouldn't be too much practical difference between the protocols because it's simple transfer from one way... Gateway to another. But in a future where you have a network of gateways and we want long list sessions, and you might have, imagine, 10 different concurrent requests to one gateway, then gRPC will be superior to for new HTTP.
[00:53:16] Hyojin Song: Thank you.
[00:53:34] Claire: Thank you. I don't see any other hands. So, Denis, over to you for the stage zero registry work.
[00:53:41] Denis Avrilionis: Okay. Thank you, Claire. Do you see my screen?
[00:53:58] Rafael Belchior: Not yet.
[00:54:16] Denis Avrilionis: Yes. Okay. Perfect. So here I'm, wanted to take some time to wrap up the... I mean, give the overview of what has been discussed in the, between the last meeting, yeah, TEF and now on the concept of registry. Connected to that, there is also the discussion about stage zero. So I will be brief. There was a few things that I wanted to share regarding, first of all, the connection between these concepts. So in the stage zero draft, we are illustrating the connection between gateways, networks, and registry one or many. In the use case of establishing a transfer context. So, basically, what we are illustrating here is the fact that, when you have assets registered in a network and there is a negotiation eventually among different gateways on, with concurrent access to these assets, how we could define a transfer context that can capture the fact that there is a specific execution instance of sub p referring to these assets that exist in network one and how these assets would be transferred over to network two. In the context of executing SAPP and prior to that in negotiating stage zero, during stage zero, the different elements, that required, you know, to be defined for the execution between the two gateways. We're using the the registry to capture any sort of persistable artifact that is, required for the SAPP core execution. And the transfer context, of course, that is illustrated with the sequence diagram, it's one of them. So the idea here is that, the networks are, passive in a sense that gateways access the network, but the network don't know, about the gateways. However, there is a binding of the different assets, that exist in a specific network for a given, transfer instance. So, this is the thing that you see in the diagram, in step one to three. There is a propagation of the transfer context from the application one to application two in order to prepare in steps six and seven to prepare network two to receive, the the assets. And there is a key, operation here in eight and, which is the binding of the two gateways and the registration of the transfer context on a given registry, which then can trigger the execution of SAPP core. So here's just one example of the kind of, artifacts that are required for to be registered as persistable information on a given transfer context in a registry. But more... Even more important is to abstract a bit in order to define something that exists in sub p, which is also something... A generic pattern that we can see in other, transfer protocols. So if I abstract a bit in terms of the the life cycle of the assets, how, SAPP could be perceived is that, first of all, is that we have to, create somehow the assets in a given network. So it's like emissions of assets before sub p could even be executed on a network. And then when we execute sub p, there is this atomic operation of, creating, the assets on the target network and deleting, obliterating the assets from the source network. And for these things to happen consistently, the gateways at many point in time need to verify the integrity of the SAPP execution, whether this is in stage zero in order to make sure that the assets are, bound to the specific gateways for the specific transfer context for that particular transfer instance. But also during the execution of, SATP, there might be things like accessing eventually logs in order to recover or other artifacts artifacts that are necessary that should be registered to guarantee that the gateways can execute SATP consistently. So this notion of registering things, verifying things, and executing, it's a pattern that we can find also in other protocols outside. And I have here the... An example of the architecture of Chainlink with the cross transfer interoperability protocol, the CCIP that they have defined. So the interesting thing is that even though the architecture is completely different from SAPP, there is this pattern of registering information in a registry. Same thing immutable and append only, like the one that we are discussing in the context of sub p. There is the need for verifying during the execution of the transfer, verifying information that could be reliably be registered in the registries previously. And there are components like the gateways that execute the protocol. So this... It's interest... It's interesting that there is an obstruction of the registration verification and execution pattern that we see in SAPP and also other protocols related to transferring assets over the... Over networks. So if we see this pattern in what we're discussing here in SATP, we can find it in the in the notion of the the the registry. So the registry is there in order to register any sort of data that are necessary for the execution of SATP, be profiles for the semantic definition of assets, the things that we have also discussed in the past about identification of the assets themselves or the networks or even the gateways, as well as, instance level artifacts like the transfer context, eventually the logs or other things. So this is the registration part. Of course, there is this verification, part, which is how, consistent is the management of the life cycle of the asset through eventually smart contracts in the networks in order to make sure that the mint burden paradigm to maintain the asset properties of SATP properly executed, in the in the networks. And, of course, the execution part of this pattern, which is the SATP implementation of SATP itself, like also Rafael demonstrated in the implementation of hyperledger peptide. So from that, I wanted to be, you know, briefly present the fact that here we have in SAPP a pattern, which is a pattern might be found in other cross chain implementations protocol... Protocols where we need to register and very... Issue, register, and verify information in order to be able to consistently execute the transfer. So that's all. Wanted just to be brief and give time back to you. If you have questions, I'll be very happy to answer them.
[01:02:45] Rafael Belchior: Yes. Rafael? Hey, Denis. Thank you for your presentation. I think this is very important work that it's necessary to be to be built upon on core for the whole process to work end to end. So my my question is on the... So the registration verification execution pattern makes a lot of sense to me having studied some of these protocols. How do we do that to networks that are opaque? So for example, if a gateway is in front of a private blockchain, of course, we can register the... These these artifacts somewhere public, but verification is by itself a bit harder. We have some protocols that allow to verify internal state of private blockchains, but those are fairly complicated. Is there a way we can verify without relying on... At the stations?
[01:03:45] Denis Avrilionis: Very good question. Thanks, Rafael. I mean, in most of the the time that what we have seen in other protocols, and I think it's a general pattern, it's some sort of zero knowledge or selectively disclosable information. So the fact that we have a registry does not mean that all the information about a specific execution trace or assets should be publicly available. So some sort of ZK proof or selective disclosure eventually, with some extra rights that are assigned to different parties, might be one approach that is not... You know, it's quite common, I think, to, many private blockchains, I think.
[01:04:30] Venkatraman Ramakrishna: Alright.
[01:04:30] Rafael Belchior: I don't know what you're I think. I... That that was one of my ideas I wanted to hear yours before introducing biases. Yes. But we we could rely on cryptographic primitives such as zero knowledge proofs for that, of course. But then the problem is deferred to how do we know that the cert... The right circuits were installed, per... Let's say, installed or deployed in... Into the network. Right? How do we make sure the the process Mhmm. Perhaps it has to do with the gateway at the station discussion we had many years ago. Right? If a gateway... If we can attest the state of a gateway, meaning, like, what versions of the circuits, what versions of the keys they have, maybe maybe this whole problem boils down to that. What's your take?
[01:05:23] Denis Avrilionis: Yeah. And, definitely, the the workaround selected disclosures is also something that maybe we can get inspired from because the whole discussion about, you know, the disclosing... I mean, persisting information that you'd later on come and verify or selectively disclose with the ability to verify that the original information has been, registered. It's something that is used quite often in, in decentralized protocols. So I guess that it's something that has been addressed already. And there's also the tension with... Always the tension between the blockchain that is public and the information that should remain, private or or secret. But I believe that having a trace somewhere in the registry that can guarantee that a given point in time, some piece of information existed no matter if there is a ZK or select disclosure or or whatever. It's it's... I think it's an important one.
[01:06:34] Rafael Belchior: Thank you.
[01:06:43] Denis Avrilionis: So thank you. There's no other question. Yeah.
[01:06:46] Claire: Thank you very much, Denis. Efan, over to you.
[01:06:52] 張一凡: Okay. Let me share my screen. Customer screen?
[01:07:10] Martin Gfeller: Not yet. It takes a while.
[01:07:14] 張一凡: Okay. Can I see this?
[01:07:26] Rafael Belchior: Yes.
[01:07:28] 張一凡: Okay. Thank you. And this is my first time to join this meeting. And let me share my research that is finished as my PhD work at the University of Tokyo with my supervisor. And, yes, let me start. The key key takeaway is here. We have three points. The first one is we proved the SAP is secure if the gateway is trusted and the gate... Trusted gateway is secure. And just two compromised gateway can fake a lock, and the the other gateway cannot detect it. So, three, the signature from the ledger own body ledger can fix this one. So we suggest strength... Strengthening SAP so that it can be proved the security with some cryptographic proof technique. Our result is here. We modulate SAP core as a cryptographic protocol. The key part is stage two. The gateway a locks our set, assign a lock assertion and send it. Gateway b verifies the signature. If both gateway are honest, SAP is correct, atomic, and unforgeable. We showed this with a game based analysis, and that is very standard security proof protocol. So SAP is secure as as a... Is speech fade... Specified. But what if a gateway is not honest? So here is our program. The gateway holds a sign in key, so they are attractive targets. Suppose gateway a is compromised. Gateway a lock nothing, but still sign a lock assertion. The signature is valid, so gateway b accept it and meet the asset in the ledger of... Ledger b. The gateway b cannot see the source ledger in some time. For example, if the ledger a is enterprise private ledger, so gateway b only gets the information from the signature itself. And signature gives accountability later, but it does not prevent the loss. Also, lock does not have to be final. On the same later, it can fork and undo the transaction in the source ledger. So... Or fix change only that goes into the lock assertion claim. Insert one gateway signature. Instead of one one gateway signature, we use signature from f plus one validator of the source ledger. Each validator signs only after the lock is final. Macro proof shows a lock transaction within n is greater than or equals three f plus one, then at least one signer is honest. So fake a log cannot get enough signature. This is not a new bridge, like, or harmony. The signer as laser's own validators, so the evidence is as strong as the laser itself. This fits as a new claim format. No new message. Verify... Verification takes under one millisecond. That is very lightweight. Our propose... Proposal is here. Two strengths in the SAP so that security proof can be done even with a compromised gateway. The first now takes only one, security consideration say that compromised gateway can fake a lock. Two, lock assertion should refer only to the final lock. Three, if the transpose become abstract, list the security property, SAP needs from it. Next, after core, adds validator back ended frame format. We prove it secure with game based on the UC analysis. UC is as universal composability that is a a more strict analysis of just the... Some cryptographic protocols. So there is a... Or finding on the proposal. And so sorry. That is fine for my role. That is my PhD work, and I'm here for personal capacity. I can answer any question on the... To happy to help to to discuss with this topic. Thank you.
[01:13:25] Claire: Thank you very much for the overview. It's really, really helpful. Any questions? There's no hands raised at the moment. Yep. Rama. Thank you.
[01:13:35] Venkatraman Ramakrishna: Yeah. Thanks,. Yeah. These are all very good issues to identify. I think we we have talked about these problems, like, in the past history of this working group. Just wanted to... Maybe we can kind of offline about this. But there's a... There are drafts pending on exchanging views between blockchains, and that kind of covers this part. It it doesn't talk about the specific proof mechanisms, but it does describe at least the protocol by which legislate and proofs can be shared between different things. Now one thing I'll say that this... The static protocol... The static code protocol that you were trying to draft was meant to be agnostic to the networks. So the... It... It's actually meant to not just transfer asset between blockchains, but between legacy systems as well or between legacy system and the blockchain. So that's why the the need for a consensus based attestation was not really identified as a as a core part of the... Of that people. But, yeah, I I totally agree with you, and that's something that we have worked here in in our IBM research group for for a long time. I mean, we we worked on this kind of thing, like, about sharing data from a private blockchain. We wrote some papers several years ago on this, so we're happy to discuss this with you on the meeting desk.
[01:15:07] 張一凡: Yeah. Thank you. So it's based close to your comment. That's the very same thing because the decentralized trust in... Also, we need that in the gateway. So that is the very same topic, I think.
[01:15:26] Venkatraman Ramakrishna: Yep. Thanks.
[01:15:28] 張一凡: Thank you.
[01:15:32] Claire: One ask for me. Are you able to share this slide deck to the mailing group? That would be nice to have it.
[01:15:39] 張一凡: Yes. I think I I can I can share that? Thank you.
[01:15:47] Claire: Okay. I don't think we've got any other questions coming through. Next steps, I think, back to the mailing list for a few questions that were raised in today's session. IETF one two seven, I think you may have all seen where there's no... So we'll we'll find out what we can do there and and communicate to the mailing group. If not, we will have another session fairly soon after as soon as we can with the ITF regulation. Is there any other business to raise today? Appreciate you all staying fifteen minutes later. No? Okay. Thank you very much for everyone for your contributions. It's been a really... Oh, hi, Denis.
[01:16:40] Denis Avrilionis: Thank you.
[01:16:42] Claire: Oh, thank you very much. Cheers, guys. Take care.
[01:16:46] Venkatraman Ramakrishna: Bye. You
[01:16:47] Martin Gfeller: too. Thank you. Goodbye, everybody. Have a nice day.
[01:16:53] Hyojin Song: Bye bye.