Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added Open Discussions section; included hyperlink references. #14

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Added Open Discussions section; included hyperlink references. #14

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 11 additions & 7 deletions call-notes/call_1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,10 @@ Meeting Duration: 30 mins

- Outline process for critical issues when there's multiple validator clients

## Open Discussions

- When do the Solana specs change in relation to network upgrades? [22:37](https://youtu.be/XZhy9VFGKZc?t=1357)

## Meeting Notes

### Introduction
Expand All @@ -23,11 +27,11 @@ Video | [00:00](https://www.youtube.com/watch?v=XZhy9VFGKZc)

**Jacob Creech**: This is what we're considering as the first Core Community call or the first Solana Core Developer Sync. What we're hoping that this turns into is a way for developers on the Solana protocol to sync on changes that are being made, feature developments that they're thinking of, and proposing changes on Solana so that we can more collaborate together as a whole.

Ultimately it's up to you all as the engineers to make up as you best wish of what this call looks like. In future calls we'll call for an agenda if people want to put forth what they want to talk about on the agenda side. The first item that we want to discuss is like what do you all think that this call should look like and then later we'll also talk about SIMD and what that process looks like so that we can make proposals and actually use it to make changes, and keep aligned on changes on Solana.
Ultimately it's up to you all as the engineers to make up as you best wish of what this call looks like. In future calls we'll call for an agenda if people want to put forth what they want to talk about on the agenda side. The first item that we want to discuss is like what do you all think that this call should look like and then later we'll also talk about [SIMD](https://en.wikipedia.org/wiki/Single_instruction,_multiple_data) and what that process looks like so that we can make proposals and actually use it to make changes, and keep aligned on changes on Solana.
Go ahead, Richie


**Richie Patel**: All right! I think generally this would be most useful to have an online forum where client teams can discuss changes that affect everyone, mainly protocol breaking changes that Solana labs, Jito and Firedancer, and so on would have to implement. I think we should probably start with a process where we first specify something in the SIMD and then go forward. Other things will probably be things that actively concern mainnet and require call intervention to be fixed, I guess that that would be the Quality of Service related incidents and so on. Was there a written agenda or a proposal for the agenda for this call? I think I saw something, I don't fully remember.
**Richie Patel**: All right! I think generally this would be most useful to have an online forum where client teams can discuss changes that affect everyone, mainly protocol breaking changes that [Solana labs](https://www.linkedin.com/company/solanalabs/), [Jito](https://www.jito.wtf/) and [Firedancer](https://jumpcrypto.com/firedancer/), and so on would have to implement. I think we should probably start with a process where we first specify something in the SIMD and then go forward. Other things will probably be things that actively concern mainnet and require call intervention to be fixed, I guess that that would be the Quality of Service related incidents and so on. Was there a written agenda or a proposal for the agenda for this call? I think I saw something, I don't fully remember.


**Jacob Creech**: For this specific call it's to talk about what we both most want out of this as well as talk about the SIMDs, and then anything else that you all want to bring up.
Expand All @@ -48,7 +52,7 @@ go about making contributions by engaging here, by making an informal proposal o
So just trying to feel out what people think is best there and then as we go on like to be able to kind of dig into the actual details of like: Okay, what do people actually feel about this particular proposal or that code change, etc.


**Jacob Creech**: Cool, and then to kind of like further jump-start the conversation, I'll drop in the chat the SIMDs that we currently have or that we're working on. We recently kind of launched this process of how we can propose protocol changes to Solana that would be breaking changes something that's a big change economic wise, and what we can do is everybody here can create a proposal that will change how Solana works and then we can use this to discuss what is different, how different changes work, how it affects all of us, especially between Firedancer, Jito and working with the Mango folks. How we can create or keep in line of the big changes coming on Solana in the future, especially when
**Jacob Creech**: Cool, and then to kind of like further jump-start the conversation, I'll drop in the chat the SIMDs that we currently have or that we're working on. We recently kind of launched this process of how we can propose protocol changes to Solana that would be breaking changes something that's a big change economic wise, and what we can do is everybody here can create a proposal that will change how Solana works and then we can use this to discuss what is different, how different changes work, how it affects all of us, especially between Firedancer, Jito and working with the [Mango](https://solana.com/ecosystem/mango) folks. How we can create or keep in line of the big changes coming on Solana in the future, especially when
there are feature activations. How do we do that across teams etc.

### Challenges in making public repositories and their possible solutions
Expand All @@ -60,7 +64,7 @@ some of those are things that we also discussed with Dan a little bit earlier, a
problems. None of this is anything that I have really prepared remarks on or anything but one of the things that already exists in this. We talk about specs is part of our job is to essentially come up with specs for what the existing protocol is from the current code and there have been some repos set up in places like the Solana Foundation. I know there's a lot of kind of comments on that and that's also somewhat a prerequisite for work we're doing
internally where we've engaged with various experts in formal verification and whatnot, and it's very difficult to formally verify if we don't actually have a spec for doing that.

So, at least from the kind of specs repo read-write access and whatnot, I’d kind of direct things in that direction unless there's a broad consensus in the community we don't want to have those. I don't really see that as not being an option for the long term if we want to have multiple validators or whatnot and, you know, kind of put people in that direction. I think when it comes down to those that’s not the only repo, like there are the internal repos that we're developing, there's obviously the Solana Labs repos, other people's repos that are kind of sitting around here. We spent a lot of time in the initial discussion when we were asked to look in this area as to what was the right model for doing the engagement and we were deathly afraid that we had two different organizations, different cultures, different development styles, different languages and all that, that if we were to try to do stuff in the same repo it'd be disastrous. It wasn't just that kind of abstract concern internally, Jump has a lot of internal communities with the various trading groups and so on and so forth, and you know doing everything in a common repo just tends not to work. So we've done a lot of stuff internally just for you know non-crypto-related things where we essentially develop stuff at boundaries between repos and come up with interfaces, be they shared memory interfaces or whatnot, and a lot of the stuff that we've been planning on here is to essentially iterate independently in our own repo. Let Solana iterate in their repo. Use the specs that we're doing to essentially define boundaries both from the protocol works but also ways that we can divide stuff up and componentize the existing validator and then swap out various parts as we go and do that. A lot of that is being done at process boundaries, so we don't have to have a whole lot of friction or tight integration between organizations and you know those kinds of logistical problems that can do.
So, at least from the kind of specs repo read-write access and whatnot, I’d kind of direct things in that direction unless there's a broad consensus in the community we don't want to have those. I don't really see that as not being an option for the long term if we want to have multiple validators or whatnot and, you know, kind of put people in that direction. I think when it comes down to those that’s not the only repo, like there are the internal repos that we're developing, there's obviously the Solana Labs repos, other people's repos that are kind of sitting around here. We spent a lot of time in the initial discussion when we were asked to look in this area as to what was the right model for doing the engagement and we were deathly afraid that we had two different organizations, different cultures, different development styles, different languages and all that, that if we were to try to do stuff in the same repo it'd be disastrous. It wasn't just that kind of abstract concern internally, [Jump](https://jumpcrypto.com/) has a lot of internal communities with the various trading groups and so on and so forth, and you know doing everything in a common repo just tends not to work. So we've done a lot of stuff internally just for you know non-crypto-related things where we essentially develop stuff at boundaries between repos and come up with interfaces, be they shared memory interfaces or whatnot, and a lot of the stuff that we've been planning on here is to essentially iterate independently in our own repo. Let Solana iterate in their repo. Use the specs that we're doing to essentially define boundaries both from the protocol works but also ways that we can divide stuff up and componentize the existing validator and then swap out various parts as we go and do that. A lot of that is being done at process boundaries, so we don't have to have a whole lot of friction or tight integration between organizations and you know those kinds of logistical problems that can do.

With respect to protocol-breaking changes as we've been going through a lot of stuff and checking more stuff in, we had a lot of ideas and we've spent a lot of time thinking about how we might, you know, bring them to the community. I think one of the things that already exists that we were planning on is we do have some scope in our development plan for essentially doing proof of concept designs and like some of the stuff that we were thinking about doing is just like, you know, we'll set up a proof of concept over here to essentially come up with reference implementation and then bring that to a community as opposed to just having an open-ended abstract discussion to the effect like we don't like this, maybe we could do it this way then have everyone just be kind of like well it's not obvious that'll be better or not, and so at least as far as protocol breaking changes are, at least intent is, we would make recommendations but only make those recommendations after we had some working code to show how those things work.

Expand All @@ -70,7 +74,7 @@ Sorry for a bunch of rants, I don't know if that necessarily addresses the point
Video | [10:00](https://youtu.be/XZhy9VFGKZc?t=600)
-|-

**Richie Patel**: I think we can take a lot of inspiration from the Ethereum process because that has proven to work quite well at scale and the way they do it is fairly similar. So for any non-trivial change to these specifications and whatnot, usually when you check in an EIP, or
**Richie Patel**: I think we can take a lot of inspiration from the Ethereum process because that has proven to work quite well at scale and the way they do it is fairly similar. So for any non-trivial change to these specifications and whatnot, usually when you check in an [EIP](https://eips.ethereum.org/), or
in our case in SIMD, you also have a proof of concept in your own repo and then at least start to
think ahead about how another team might Implement that.

Expand Down Expand Up @@ -105,7 +109,7 @@ Video | [15:11](https://youtu.be/XZhy9VFGKZc?t=911)
Solana Foundation has this authority since, with the exception of Jito, we're just starting out hitting mainnet. In the long term, it would be nice to maybe define a set of people. I know this always tends to exclude people but I would maybe define consensus like that there is no big agreement, there's like general you know acceptance of a change even if it's not a direct confirmation from each team.


**Jacob Creech**: Yeah, as part of the first SIMD it's there's no obvious outspoken disagreement and that if there is agreement from the majority of core contributors, you can move forward by who has access to do write, triage, or to maintain the repo of SIMDs. I wrote up an access policy that is very similar to how Mozilla does it and how they give access to write or to triage different issues, so that is under review. We can create that list of possible merge-access people. It's really it's both a social consensus as well as like a technical consensus. If someone abuses that power it can easily be taken away as well.
**Jacob Creech**: Yeah, as part of the first SIMD it's there's no obvious outspoken disagreement and that if there is agreement from the majority of core contributors, you can move forward by who has access to do write, triage, or to maintain the repo of SIMDs. I wrote up an access policy that is very similar to how [Mozilla](https://www.mozilla.org/en-US/about/) does it and how they give access to write or to triage different issues, so that is under review. We can create that list of possible merge-access people. It's really it's both a social consensus as well as like a technical consensus. If someone abuses that power it can easily be taken away as well.


**Dan Albert**: I think there's maybe also been some questions, and tell me if you think this often the weeds are out of scope here, but I think it's good for us to kind of feel out what these kind of processes feel right here. I think there's also a lot of less process heavy and more just sort of navigating the space questions some folks have come up with just like, Hey I wanna like I have this PR open against say the Solana Labs repo right because I'd like to fix a bug or I want to make a change whether it's a small thing or a bigger thing but they're a community member or maybe it's someone
Expand Down Expand Up @@ -149,7 +153,7 @@ We also are trying to minimize the complexity and the surface area of those inte
Video | [21:30](https://youtu.be/XZhy9VFGKZc?t=1290)
-|-

**Richie Patel**: I remember as part of the three repos we created for these inter clients, local APIs there were first of all these specs, the SIMD, but there's also a validated APIs repo that Solana Foundation created, and originally that was the plan to have all the C structure definitions and so on posted there but I think this can quickly get quite complicated if that needs to be compatible with like three different CI processes and build systems and so on. So I'm not too sure what the best platform would be, maybe we just copy headers between clients and socially ensure that they don't get out of sync instead of using any complicated tools.
**Richie Patel**: I remember as part of the three repos we created for these inter clients, local APIs there were first of all these specs, the SIMD, but there's also a validated APIs repo that Solana Foundation created, and originally that was the plan to have all the C structure definitions and so on posted there but I think this can quickly get quite complicated if that needs to be compatible with like three different [CI processes](https://en.wikipedia.org/wiki/CI/CD) and build systems and so on. So I'm not too sure what the best platform would be, maybe we just copy headers between clients and socially ensure that they don't get out of sync instead of using any complicated tools.


**Dan Albert**: Yeah, I'm happy to remove that validator internal API repo. It hasn't seen any activity since we kind of kicked that idea around a while ago, because it's really not, like you said, it's not a protocol definition thing, it's more of an implementation for convenience between multiple teams.
Expand Down