 My name is Boris Mann. I am an organizer that helps out with ETH magicians. I also have founded a company with Brooke, who you'll hear from in a little bit, called the Special Projects in Decentralized Engineering Company. And we work on open source low level infrastructure for Ethereum and other decentralized protocols. And with that, why don't we do an intro of all the participants. I'm Jamie, and I work at the foundation... What's your surname? Full name? Yes. Jamie Pitts, and I work at the foundation. And I also work with Ethereum magicians. And it's been a lot of fun working for both. I'm Charles Neville, and my address is... I work at the Enterprise Ethereum Alliance. So... I'm Brooklyn Zelenka. I, as Boris mentioned, we work together. I'm the CEO and Chief Scientist at the Special Projects in Decentralized Engineering Company. And I've written about 5% of the ERCs. Hi, I'm Bob Samoil, previously of the foundation out of Consensus and EEA, Ethereum community person. Hey, my name is Alex Voto. I'm from Consensus, and I volunteer some of my time helping EEA groups form. Hey, everyone. I'm Conas Fenson. I'm the technical standards working group chair of the TechSpec working group chair of the EEA. I'm also the founder of a company, BLK.io, and the author of Web3J, the Java library for working with Ethereum. I'm Mick Johnson, my microphone's not on. I'll talk later. I'm Menson, I'm EIP editor and also the leader of the E&S project. Fantastic. Now we know all the players. I think we're going to start with the EAPS process. How many people in the room are confident that they could currently explain the Ethereum improvement proposal process? One. Do you mean accurately or just... Two. Okay. Four. Amazing. So we're going to try and up that number from four to at least eight, or maybe make some of those four flip and cause them to question whether they're correct or not. So we know that this process is not something that a lot of people have necessarily engaged with, and that's definitely something that there's a desire to improve, make it less scary in general, and improve the quality of it improves the protocol for all of us. And this is one of the roles that we're trying to help with at Ethereum Magicians. Although it's sort of outside of the process, it forms a discussion and organizing layer around it. I will start this off by how many of us here are familiar with EIPs, EAPS, improvement proposals? How many of you are familiar with other kinds of standards that are out there? Okay, that's good. There's familiarity. Okay, so this is about how to Ethereum Improvement proposal, and you might want to create a standard in the community. You might want to create something like this famous standard, ERC 20. So these are some resources. You might want to pull them up on your phone or computer to follow along. A very special one, an important one is EIP 1, which is sort of the procedures, almost a constitution for the process. And it's all described right there, how it works. So an EIP is an improvement proposal, and it describes a standard. And most of us know EIPs as core, like the core improvement proposals for a forking change. And those are widely publicized. And many of us are familiar with ERC 20 and many of the ERCs. These are application level standards. And, you know, this is a distinction, it's a subset. And in general, what is a technical standard? That's something to keep in mind. It's a formal document. And often these kinds of things take years of deliberation. So much, you know, just gathering of stakeholders and engineering that goes into these things. So the process, what it's for, it's essentially to create high quality proposals that are accepted by the community. And a lot of times in the community it's been, it's kind of vague, right, what's community. And that's coming to head. We're starting to understand that the community involves stakeholders. And it's not just an amorphous concept. And so you want the best input you can get in the process. And you want buy-in from stakeholders who want that consensus. And one thing to note about EIPs, it's in a Git repo, specifically GitHub. And GitHub issues are critical to it. It's a critical piece of the EIP infrastructure. And you can just go direct to GitHub and see it there. So what is the work involved? These are, this is specified in EIP 1, like what is involved. And the EIP 1 describes the format and that, you know, giving you recommendations as to how you're supposed to proceed, you know, that you're supposed to format it in a certain way, you're supposed to find consensus. What EIP 1 does not tell you, it's like the subtext to that as you develop. Any technology. And there are EIP editors. They're involved in the process. And their responsibilities are very specific. They don't weigh in on an EIP as you might assume they do. They're very much about formatting and moving the process along. They don't judge what you're doing. In the sense that they're like administrative. They see it through. They run the process. And I'll have Nick, if you would, at any point. Nick here might weigh in. Happy to? Yeah. He's an editor so he doesn't weigh in. Yeah. I have no idea what was posted. That's right. But this is not the EIP process. We have Brooke here as well, a user of the system who has submitted ERCs. And here's a list of the current editors. You may know their names. Who in this list are most active, do you think, Nick, in terms of like moving it through the process? Are there any dormants? Besides myself, probably recently Casey and Hudson. Nick Savers has done a bit. We're all kind of like none of us. This isn't our full-time job for any of us. So it tends to come in fits and starts, unfortunately. Something we'd like to smooth out. And part of that is automating the process better. I see. Is this list other than on the slide public somewhere? It is in EIP1. Great. Would you like more community involvement, more people to volunteer? If there's a person who loves editing documents, then we want you. Go ahead, yeah, please. At any point, anyone can kick in and ask a question, absolutely. What's the procedure for adding an editor? Someone has to stand up and say, I would love to do a whole lot of work for fame and glory. For little to no recognition. So that is step one. The rest is slightly ill-defined, but the general process is propose an amendment to EIP1, adding yourself or someone else against their will as an editor, and get approval from enough existing editors, where enough is kind of ill-defined, to get that EIP merged. Technically, like any EIP change only requires approval from one editor, but for changes to EIP1, we've historically tried to seek a real consensus amongst editors since it changes the whole process. And when you say adjustment, you mean make a pull request, yes? Yes. And we'll go over that. We're going to specify that, because I think people might not understand the process. You'll ask the person whose name got put up whether they're actually willing to do it, right? Did you say there's a volunteer? No, yes, but he's called Boris. No, I thought you were a volunteer. Okay, so here's one thing that people might not understand. They might think there's only two kinds of EIPs, because those are the ones in the news, core and ERCs, right? But there's actually more. You have track EIPs. You have core, which basically means improvements requiring a consensus fork, and Brooke, you had pointed out and had put it in here, but there's another distinction that actually seemed kind of vague to me. Yeah, so any EIP1, it says it's requiring a consensus fork or things that may not, but are of interest to core devs. Okay. And I found that I wasn't sure how to interpret that. So there's networking EIPs, interface EIPs, and would JSON RPC be in that category? I know it's not defined as an EIP, but would it fall to that? It's not defined. I would say it probably belongs in networking, yes. Okay. Sorry, in interface. Oh, okay. Again, confusion. That's a good point. And of course ERCs. And then you have informational EIPs. And this is an interesting one, because I think this is actually quite open. I think more people should submit these, right? If you wanted to write like a best practices for contract development, then that would absolutely be welcome in an informational capacity, as long as you could demonstrate that there was consensus on these being good practices, and it wasn't just your personal idea on how to do it. Yeah, this could be the new medium, right? I mean, we're using medium. This is the hard thing right now. There's technically a Boris versus Nick blog post that still has to happen at some point, where we talked a little bit in Berlin in the summer of whether the EEP process could use top of funnel curation to reject more EEPs, or whether in fact, so that's the Nick version for the purposes of debate, or whether in fact the Boris version of all the EEPs all the time, let's have a thousand EEPs bloom and we'll scale the process of moving it along, that is still undefined and blog posts yet to be written. So unsurprisingly, the person who's an editor wants fury EEPs to edit, and the person who isn't wants more. Yeah, if we do that, I will volunteer you, Boris. And then we have meta EEPs, which are the process, the decision-making process, and this one it says surrounding Ethereum, which sounds like really big or something, but I think it could be a lot of different things could become meta EEPs. So these are the different types of EEPs. An ERC is an acronym for ERC. Request. Ethereum Request for Comments, named after RFCs. Which is the IETF Request for Comments. In general, what we're doing here is we're demonstrating that we would like everyone to call out things that they don't understand. And I will attempt to be, as you see we've demonstrated, we're trying to do the, there are no dumb questions, so that we expand things like acronyms. This will be especially important when we get into enterprise land, which is made entirely of TLA's, three-letter acronyms. And ETLA's, extended three-letter acronyms. So we're going to focus on core EIPs. And what's interesting is, I think most people in the community would probably be submitting ERCs, but I think understanding core EIPs is really important. So, who are involved? And you have these three main groups. And the theorem core developers are the ones you hear in that conference call, once every two weeks. And are there other stakeholders in this process? There might be. So, the workflow, the workflow, it has to do with starting with the template, there's a template in the repo and you submit a pull request. You fork the repo and you submit a pull request when you're ready to submit your EIP. That's a flow that perhaps people are not used to. What do other standard bodies do for this kind of thing? How does that work? Because I know this happens in Python, this submission. So I'm not familiar myself with a lot of bodies. The ITF operates their own issue tracker, basically. It has a specialized process for submitting and updating RFCs, which has evolved over time. But it's designed specifically for it. Should we move out a bit? Yeah. And essentially what you're doing is you're submitting pull requests and trying to pull it through these steps. And every one of these steps has a role in some special conditions. Otherwise it's not going to make it out of that step. So the first step is work in process. And you create the EIP through the pull request and it's reviewed. And I believe that there's not much restriction to submitting one of these, am I correct? We have a question. Oh, yes. What you said about the ITF is correct. But all of the newer working groups, almost all of the newer working groups in ITF do all of their practical everyday work in GitHub. Really? Almost everybody is supposed to use that. It's just convenient. So when they have a new version of the draft, that's the only time they submit it to the tracker? So they basically edit in GitHub and then yes, whenever they want to, they can submit it. Anyway, so there's just an awful lot of work that happens in GitHub now, even for ITF work. Good to know, thank you. W3C as well. Yeah. And EEA. Yes. And to answer your question about work in progress, basically work in progress isn't an official state. It's what we take something when somebody sends a pull request that clearly they're still working on. The first sort of official state that gets merged is draft. I see. Okay. And then to get it to draft, there's more requirements. One thing I'm interested in is this notion of agreeable. And if Nick, you could give me some insight on that. That's one thing I don't quite understand. And I see in the EIP one, it talks about what might cause it to fail to reach draft. What would you consider to be acceptable? So this is something that's evolved over time. The earlier versions of EIP one were quite vague about this. There was a lot was left to be this judgment. And I've been trying to push towards a more sort of objective process where EIP editors in the early stages at least act as effectively editors in the newspaper sense or the typographical editors. So to be acceptable, it has to pass the continuous build, which checks a bunch of stuff about formatting of it and so on. It needs to have at least the relevant headers, especially the one disclaiming copyright at the end. And it needs to be, I'm going to put the broad category of not obviously crazy. So it needs to look like something that could eventually evolve into something people would want to standardize. Okay. And this final one, okay, so there is some history behind EIPs. And it's been through, there's a long history. It goes all the way back to Python for a while. And then Bitcoin took Python's system. And then Ethereum took Bitcoin's improvement system. And, but they kept some of these things like this philosophy line here. And if you look this up, there's a lot of discussions online about it. So even now, there's still legacy pieces from way back that might cause, lead to confusion. So that's one thing to keep in mind about it. But as Nick is describing, like there's the de facto process and it might not exactly match EIP 1. Are there examples of EIPs actually being knocked back because they're not in keeping with the Ethereum philosophy? Not the Ethereum philosophy clause, no. You've never actually used that process? No. And I personally believe the philosophy line shouldn't be in there. If you want to write an EIP on the best way to boil kittens, then you're a monster, but I'll still accept your pull request. So there's a notion of last call. And again, it's the agreeability concept, but then there's a set deadline for it. And then there's two levels of fail on this. And I'm assuming fail, just a regular would be, it doesn't make it to last call. But I call this the second one fail plus plus. It gets knocked back to draft. And has that happened? Have you ever encountered that before? Since we introduced the last call process about three months ago, we've only had a few EIPs go to last call. One of them went back to draft. And I wouldn't really categorize it as a fail because last call is an opportunity to get more attention to your draft. It could be in a state where you believe it's mature, but learning about things that you hadn't considered is an opportunity to make it a better standard. Okay, okay. My language may be too strong. Okay. And then there's accepted. And this means, in the case of a core EIP, that this change is now in the hands of the client developers. And... Do we know what we mean by client developers? So, Geth, Parity, Pegasus, Trinity, et cetera. And there's this... I'm sorry, go ahead. How does that actually work out in practice? I mean, you know, I am sitting in my garage in Bangalore writing a client. Do I come along and say, hey, guys, I'm writing a client. So I should be on that list. Yes. And we assume that the guy in Bangalore is doing that. We'll figure this out and come along and say so. So there's a nice sort of objective threshold here, which is if your client can sync to mainnet and keep up, then you've demonstrated enough technical competency to contribute to the process, basically, as a core developer. And is that sort of a formal thing that you do of... No. Yeah. But it's highly visible. Yeah. So I think that's the thing is the... For instance, there is not a canonical list of all-core devs. But generally, if you're working on an active client, you are invited to join the all-core devs calls. And then some of these EAPS might be listed for discussion. Again, using GitHub. GitHub.com slash Ethereum slash PM short for project management, where the calls are organized and what exactly will be discussed will come up. And Hudson is the cat wrangler of that all-core devs call. Is that the correct title? I think so, yes. And that calls an open... It's open to a public call as well. Yeah. It's also live-streamed and then recorded on YouTube so it all can be reviewed. Although the people who are actively speaking are the all-core devs only. Yes. If you want to participate, I'm sure that if you pinged Hudson, that you would get on that call if you're one of the client implementers. And as Nick said, it's really clear if a client is viable or not that it's on the network. And generally, other people are sometimes invited to come on the call and talk live to all-core devs. That's right. There's been key stakeholders invited to certain calls. As well as authors of core EIPs. Yes. Yeah. Mm-hmm. Yeah, and there's an interesting clause here and that's the three viable clients have implemented to reach final. And this final designation... Nick, I'd like you to weigh in a little bit on that if you... Yeah. So currently the EIP process is still quite entangled with the all-core devs process. So in my mind, what we have is effectively two separate things. One is standardize on a set of changes or a technical spec of a thing we want to do in Ethereum. And the other is schedule a hard fork for it and push it out to the main network. But the reality is that you can standardize things that don't get put on the main network because we have more than one Ethereum network out there and there are private networks and test nets and there's Ethereum classic and so on and so forth. And I in the long run would like to see more separation between core devs and the standards process. The standards process should standardize things that make sense and are well-written and deserve to be standards. And the client devs can contribute as contributors and they are the ones who decide what their clients implement. And specifically when we say standard or specification, what we mean is there is documentation in such a way that that standard or specification can be implemented by a client and that those clients who correctly implement that spec will be interoperable. So that's a long way of saying it but it's very important. A realization to have and that's becoming only more true in the wider Ethereum community is that specifications are in fact more important than open source code. If you have a specification, then you are that much more open. Anyone can create open source or closed source code that implements that specification without being tied to any particular repo or language or anything else. And so this describes core EIPs and there are let's say ERCs. There's many subcategories of those ERCs and how that process moves along and how those reach there... It's not... Do those reach final? Yes. And how does that work? Who would vote on that or not vote but who would come to consensus on that? I think that's unresolved. In some ways it's better established as part of the EIP process than core now I think due to some recent changes. The idea is the same. It follows the same process but without the accepted step. So it probably helps to elaborate a bit on what last call is. The basic idea is when you believe your EIP or your working group believes their EIP is mature, they send a pull request asking for it to be moved to last call and that starts at sort of a two week clock. And during that period, people are expected to submit comments like criticism and feedback and so forth. And at the end, the authors of the EIP are expected to submit a pull request or a message saying here are all the objections that were raised during the last call process and here is how they were resolved. Where resolved could be we change the EIP to accommodate it or it could be we decided that this is not relevant to our EIP. And then there's a somewhat subjective but as objective as possible process for the editors to assess whether those issues were dealt with properly and whether they were substantive enough to send it back to draft. So if you move it to last call and you have some, you know, people may raise some minor issues that you fix, then no objection to moving it to final. But if there were substantive things that hadn't been addressed before, even if you fix them, then you should probably go back to draft and keep working. And a phrase that is kind of comes from the AETF and is being used or adopted in many other places is rough consensus and running code. So the rough consensus means agree, disagree, over my dead body. And generally, if there are still people in the room saying over my dead body, those should be looked at very, very highly. Oh, we arrange it. Wait, just real quick. What's the difference between consensus and rough consensus? So at least, and people with more AETF experience can correct me, consensus implies everyone is agreed that this is a good thing. Rough consensus implies nearly everyone agrees, where... OK. Wait for the mic, please. Sorry, just... Rough consensus is the absence of strong disagreement. Right, and so it's not 51, it's not 65... Everybody can live with it. Rough consensus says no one is saying we should go down a different path. No one's blocking. I didn't mean to imply that it relied on quantity of people, but rather that there can still be objections, but they have to be addressed. But the big difference is it's not about people saying yes, it's about having no one screaming no. And I think the other thing that I didn't really grok until I started sort of observing the AETF more closely is that it's not about voting. It does not matter how many people say yes or no, what matters is the technical arguments they raise and the sort of strength of their objections. Just a quick question. Where are these comments and feedback? Where is this happening on GitHub? So each EIP when it's accepted as a draft has to have a discussions to URL, which has to be some form of open discussion forum. Common choices are either an issue opened for the purpose or a theory magician's link, but it can be really anywhere that people could engage in open discussion. I think one thing about this is how does the editor know that this has been evaluated by the right people that they've reached rough consensus and that and this is where the community comes in and takes ownership, groups together and takes ownership of certain types of ERCs or certain categories of things and that the editors, I'm hoping that perhaps someday that the editors would recognize that there's a group of people who are interested in this particular type of ERC and then that would be a working group, a ring, a little standards body just for that and then they would work with the editors to move those forward so that final actually has meaning. That's what I'd like to see as well not just because it lightens my workload but because we're seeing working groups, the theory magician's called them rings forming around topic areas on Ethereum and I would very much like to see them take ownership of areas of technical standardization and that gives the editors the more power to go to people and say this looks great, please take it to the working group and for the working group to do sort of more intensive review of their particular topic area because the editors don't have the time or the expertise to comment on everything and then it would still be possible to submit an EIP yourself directly without a working group but it's going to come under great scrutiny because the question will be is there an appropriate working group but if there is then what was the reason for not working through that process? Okay. This is just briefly about the format of EIPs these are the various this is the breakdown of what you would be submitting and it's in markdown format. Now at this point I think I'll turn it over to Brooke briefly to talk about the ERC process because of what you've been working on. Could you give us some ideas about how that is and there's so many ERCs in there and it's I myself was intimidated by it it just looks like kind of crazy so yeah. Yeah, sure. So typically we're seeing individuals or groups typically groups that want to standardize some application level interface will come up with a draft shared internally say within a company or amongst their friends when they think they have it in relatively good shape they'll either put up an issue or ideally pull a request with this in the correct format and then link it to as mentioned to place for discussions which is what we have in this slide here. This is an announcement on Ethereum magicians requesting comments and further discussion on the topic. In terms of it being intimidating I think people see just like this year the numbers and they get really scared like ERC 1400 there's a lot of these but there isn't because it's tracked on GitHub every issue that's ever been filed every pull request, every typo change so there's ERCs there's 61 currently so even though it's around what 1500 now there's huge gaps in between there so I've written 3 and that's 5% right so it shouldn't be as intimidating as that and even if there's a template that you can fill out like literally copy paste fill it out and if there's something wrong with it something needs to be adjusted or reworded typically somebody will go in there and give you a hand it's actually very it's not adversarial everybody's trying to make the whole system better which is great and then forums like Ethereum magicians are very helpful people can organize them in tags people have interests or these working groups can form and move the city art forward why do we have issues and pull requests what's the distinction between those two historically people opened either so the original EIP's repo was created with a directory for EIP's and the intention that at least final EIP's would all end up in there however people started opening issues as drafts and sort of actively editing them and using that as a discussion venue as well which led to sort of a bit of chaos in terms of like what it took to be called an EIP you know whether it even had to have the hitters and so forth and where an EIP was and what would happen when ERC20 has merged and like do you close issue 20 now that it's a final and not a draft and so on so part of the revamp we've been doing is trying to sort of be firmer about that and say if you want a draft there's a pull request that's merged and the only drafts are the ones that are in this directory so issues generally are welcome to be used for discussion of open drafts non finalised EPs but you don't put the EIP itself there that goes in as a pull request and then gets merged as a file is it still useful to have issues at all or is that a distraction if we could I would probably actually close issues on the main repo with you know with the intention of sending people elsewhere for discussion I mean if I could I would have some sort of integrated discussion that was better integrated with the EIPs in general but we work with what we've got I think part of it is ends up being that so the barrier to entry to participating this is having a github username and a text editor so that's a relatively low bar and so issues and comments and subscriptions were the default messaging thread sort of thing and eth magicians has a slightly better threading notification etc interface but to be very open and accessible github is the default that people already have the tools to participate in how many discussion for a used how many different ones have been used in the 60 erc so from my experience it's basically all either issues in the repository or ethereum magicians there have been maybe I've two or three EIPs I've seen that have specified other URLs in which case I've you know gone and manually checked that anyone can sign up and comment so three or four right with the bulk github eth magicians and other roughly and eth magicians you can use your github username to log in so I think that's one of the other things that says you already have the ability so that pretty much concludes my overview of the process so I think at this point we can move to the next stage of what we're trying to do does anyone else have questions or comments on the EIPs process as it stands today I wanted to ask sorting through the proposals has there ever been the case that I don't know the community vetoed on a decision like you say okay this is not a good proposal and we're going to dismiss that has there ever been like backlash or anything like that so a couple of categories of that really one is like I alluded to earlier the distinction between standardizing things and implementing them on the main chain so there were of course the things like the various proposals around the parity multi-sig issues and they received a lot of backlash and my opinion is still that if they're technically sound we should standardize them and then the debate about whether they should actually be implemented is one for the all core devs the other is there have been one or two contributions that were just badly structured for instance there was one that basically tried to write a new EIP that would somehow change the EIP's process and you know my pushback and others was this should be a change to EIP one not something new and that's the only time I've really encountered like hard pushback on sort of the process itself I would say I've seen a couple that essentially go stale the majority of drafts go stale so some people say things like this doesn't make any sense you should update it and then the original author never comes back some of those even have authors such as Vitalik Buterin that's why EIP one emphasizes championship I have a dumb question have you seen the EIP's being accepted and then never implemented by clients not with accepted because it generally only transitions to that if there's been an all core devs and everyone's agreed to implement it certainly there are you know ERCs that have been accepted or finalized and then they're just not popular you know have you put any thought towards codifying some of these EIP's in the form of test cases and things because as somebody who's tried to implement some of them specifications in English text aren't always sufficient to describe why things are the way they are are you thinking about core EIP's or ERCs mostly core EIP's so actually there is a separate testing process there are consensus tests that are built by dedicated EF members for all of the core consensus changes there are but they don't link back to the EIP's to describe why those tests pass or fail there's no textual description of them and there has been some discussion about whether core EIP's should be required to provide their own test cases I'm sort of ambivalent about it because on the one hand it would certainly help with implementation on the other hand writing consensus tests is a very highly specialized skill set even people at even client implementers not everyone knows how to do it so as a sort of W3C which has a similar shape in some ways there's been a trend over the last few years to say you can't put a change in without a test just like more and more of the work is like you really have to actually have a test before you can put a change up because although it's specialized it's specialized work because what you're messing with is specialized work and you need to make sure you got it right and people have to be actually able to implement against it who are not the people who wrote the proposal I mean the offset I'd say to that is that currently we do have people who's dedicated job it is to build consensus tests it's fine if someone else does it but it's just a gate requirement you've got to get that test written somehow what worries me is if we push back the needing a test to getting to draft for instance our already overworked test writers are going to have to write stuff for things that nobody ever actually wants to implement it just speaks to a scaling problem it does but it also speaks to like unnecessary work in that I think it helps to vet proposed core changes before putting in all the effort of building a test suite because if it's obviously a bad idea there's no point in writing consensus tests for it why don't I mark this down I think this is thing that warrants further discussion so again this is like a live github issue to you I'm now suggesting that this is something that deserves I will open an issue around it or a place for discussion and that might be an E1 change if you had the microphone yes question hey Nick first of all thanks for emerging now for ERCs into the repository my question was around whether there's been a standard that was implemented not because it went through this process but rather that adoption made it happen so like for example as people picked it up and decided to use it before it was merged in I mean ERC 20 kind of it was submitted as a draft and it became a de facto standard long before it was actually marked as final in the repo and the version that people implemented differed in some small but significant ways from what was actually written down in the draft so about a year ago we went through and we actually made a point of updating ERC 20 to reflect the actually implemented standard and then actually finalising it so it was a real standard rather than de facto cool thank you other questions I was just wondering so it kind of sounds like for core EIPs it really does just come down to the client developers so has there ever been a time where there was a core EIP that was highly supported by the community but refused to be implemented by the client developers because like for example maybe there is like some sort of some sort of thing that could be introduced into the consensus protocol that you know that somebody researched who is like a highly skilled like PhD who just doesn't know how to code but you know for example and then like client devs didn't want to implement that so it kind of sounds like most of the power or all of the power is in you know the client developers and I'm wondering if that's ever happened before and if you guys even think that's a problem I'm not aware of it happening but I can certainly hypothesise situations like you're talking about I think the thing to remember is that these are all open source projects so implemented in a client doesn't necessarily mean the client developers themselves have to implement it just means they have to accept a pull request and if they're really determined not to accept the pull request and have your own parity or your own guess the thing is that there's ultimately like we can't write an EIP process that somehow forces client developers to implement what we want them to implement you know their time is spoken for by the organisations they work for in themselves you know and ultimately if they don't want it in their client it won't be in their client maybe in a fork of it I think that researcher implementer is sort of an interesting thing and there haven't really been community generated neither one none of those categories and it would probably not fit a sort of correctness test if you're like hey I should I think something cool should go into Ethereum so there's an expectation that somehow you gather resources but there aren't technically no barriers to it does that make sense other questions I would just comment that if you get to that problem it's a mark of success seriously yeah exactly part of the tachyon consensus cohort Hi Boris so I guess my question is about if there's any expected conflict that could occur between the philosophies of the enterprise Ethereum alliance and the larger community in terms of rough consensus and potential over my dead body types of reactions so why don't we segue straight to intro of the EEA because I think it's fair to actually have that framing first fair segue can I reuse Jamie's slides thank you we pretty much work by the same kind of process we have this formal voting system you file an issue on GitHub and then it's a private repo but all the members go into GitHub they file their issue the members discuss it and then we either reach consensus we put a formal proposal on an agenda and anyone can object to that which means we're not there yet but we either reach consensus or our formal voting rules are this very complex calculation where we count up how many meetings you attended out of the last 10 meetings and then if we have a vote we obviously haven't got consensus so we don't really care what the numbers are because we're not there yet it might be helpful to just take a quick step back and just mention what the enterprise Ethereum alliance is so the enterprise Ethereum alliance was created just over I think a year ago and it was basically a forum for large organizations in the enterprise space to actually come together and discuss best practices for Ethereum initially develop code although that has kind of currently been we don't ship code initially there was this kind of push for that but that's been pushed down in favor of actually focusing primarily on specifications for how people implement Ethereum in enterprise contexts and specifically the primary product of the EEA is a client specification for an enterprise grade Ethereum system and I think there's a lot of misconception of what enterprise Ethereum really means enterprise Ethereum could mean Ethereum mainnet if the needs of the enterprise community are met by the Ethereum clients that are currently operating on mainnet then that's totally fine but this is just a way for enterprises to say we need these kinds of privacy guarantees these kinds of messaging capabilities or these kinds of protocols or these kinds of interfaces to legacy software to make us feel comfortable with using this and protecting their customers and so initially kind of EEA was just a soup of small kind of working groups that were each interested in either industry topics or technology and it was kind of a morphis and initially it was kind of just expected to sort of bubble up and kind of emerge as a set of specs but I think in about October of last year there was a big push to actually kind of get that spec process to happen amongst a group of people whose primary concern was doing that so this was the enterprise Ethereum client specification v1.0 effort and so a bunch of people came together and actually wrote what are these requirements that we all have and then there was a group that Charles is participating in Connor chairs that basically helps kind of mediate that process taking all these requirements and then formalize those into a document and then get rough consensus on basically putting that together to get things into that specification now so that's a client spec for any Ethereum client that is deemed to be enterprise grade by the general enterprise community as defined by the enterprise Ethereum alliance but then there are industry subgroups that really just discuss hey what's happening in supply chain what are the kinds of interfaces or APIs we need in the supply chain space but also can bubble up requirements that they have that they think all enterprises should adopt based on what they've determined from their use case or add an addendum to that client spec that says if you are operating for example in healthcare you must guarantee these additional privacy guarantees and so there's these kinds of what are called special interest groups and those are industry focused and then on the other side there are these task forces which are technology focused so there's things like identity and permissioning and trusted execution which includes like off chain groups and so that for example the trust execution group just added an addendum to the v2.0 spec of the client specification that includes this extra process for people to implement off chain computing solutions so that include iExec, included Golem Microsoft, Oracleize Consensus so lots of folks working together about small organizations and large ones to kind of define these processes so that's kind of the general idea it's not just about defining the client spec it's about each of these industry use cases and kind of making that a little bit more clear. So I want to tweak one more thing which is Alex said it's for large organizations some of these organizations are as large as seven or eight people because there are organizations as large as seven or eight people who have a legitimate case for something. The question was are we going to come into conflict with the sort of public process and from the EEA side the answer is like no because that would be stupid we build stuff on top of the Ethereum, the general Ethereum thing and the fundamental reason for doing that is every piece of the puzzle that we put together every piece of the puzzle that an enterprise your local library or your local multinational super monster corporate company or your government when they develop something they pay a human being to do it and if that human being already knows all of the Ethereum stack then everything that you didn't change and specialize they already know how to do that right and you can be pretty sure that they won't make mistakes there where people make mistakes is where it's like well we invented our own special consensus algorithm called the which I did last night this will be an EIP shortly the proof of paying Charles consensus algorithm and we might actually implement that wrongly they might give their money to Boris instead because they're not used to using that piece so we actually base a lot of the stuff very explicitly on here are you want an EVM and what better choice than the EVM there's not a EVM you want a set of Json RPC APIs and what better choice than the set of Json RPC APIs let's stick with op codes that's safe so we do have it wasn't actually the EVM but it is the op code you have to have the same op codes so that the thing runs we got to the Json RPC question yes you have to have the standard list of Json RPC APIs that actually matter which turns out to be a combination of being a documentation of this is what we formally think is here and looking at what clients actually need in order to work because there are some other ones in weird places and so one of the things that we found here is a spec which is these are the pieces of Ethereum you pick up and we pick up nearly all of it proof of work is the one thing we do not require because proof of work is a way of running your local library system is a good idea said no library ever they don't need it and so everyone said you don't have to do that other than that you can run on mainnet so if you could drop in that proof of work to most of the clients you'd probably find that they would run fine but it's literally enterprises the members of the EEA and by enterprises they're all sorts of organizations figure out what it is that they need and so we go through all of the pieces of the Ethereum stack and say yeah we need that and let's do the thing that everyone does yeah we need that proof of work is a standout example of no we don't need that none of the people are building enterprise clients in the discussion all the implementers said yeah no we're not going to do that work because we don't have any demand for it unless we're also running on mainnet so making that a requirement would be done because we'll just say yeah you can put that in your spec Jamie said a standard is this technical document in my thinking a standard has another property which is that people are using it in reality because if people aren't using it it's just a spec and specific fiction is a great literary genre but doesn't make much difference to the world also I think reiterates the beginnings of the EA as well in terms of why it was formed there was a lot of companies who were doing proof of concepts on blockchain technology and of course they'd be looking at when it first started R3's cord was only just emerging but you had IBM fabric and lots of companies were running up private Ethereum networks they were running them privately because they wanted private permissioned blockchains that they could control and that's kind of disconnected from really the goals of the public Ethereum ecosystem and so in order to try and support those enterprises and also give Ethereum more of a voice in the enterprise environment as well because and this is still like a problem that Ethereum has is that naive people sort of say how can you use Ethereum doesn't that use loads of power there's a lot of concepts on it it's like these sorts of challenges and so the EA was about forming an organization which could really talk to those different enterprises really make them realise that Ethereum can be a serious technology to use in this environment but also take into account their requirements and so originally that has been very focused on as John Whelan says the 3Ps basically the permissioning aspect of it the privacy aspect of it privacy I think that there are on-chain techniques but it's kind of still accepted that off-chain the sort of corums style way of doing it is what most organizations are comfortable with just because they don't necessarily want even if it is encrypted data and it provides a degree of forwards secrecy it still might not be enough to comply with regulations that they have to abide to on the performance side of course the consensus mechanisms there that are used we do have POA which has come from the public network but then there's other ones that have had adoption there and then the permissioning side and this is still sort of a slightly grey area but at least when you have these blockchains in a private consortium network then you can control it to a greater degree so I think especially when we're talking about the different goals of the public Ethereum versus private there are fundamentally different drivers there but there's a common goal of trying to do the best we can with the technology and also ensure that it can fulfill the needs of the many so that there aren't competing technologies that can come along and displace it there's one other point as well just on the governance side that's worth mentioning about the EEA and that's that it has a board as well so if say in the spec development a formal objection is raised then that objection can go all the way up to the board and the board will have final say as well on the release of specifications too so what was announced a couple of days ago in terms of the EEA spec version 2 and the trusted compute 0.5 specification again they've all had board approval so there is some differences in governance there as well within the EEA can I just summarize the EEA shape to spit it back to make sure I'm getting it right and then if the audience has any questions so I'm hearing there's the enterprise Ethereum alliance it has a board the board runs and approves day to day operations like a corporation and it also approves the release of specifications there are special interest groups or SIGs which roughly align to industry areas like healthcare or trusted off-chain computing and then you have task force that last one not the trusted off-chain yeah and then you have a task force that covers certain technology guides certain interoperability and specification of technical areas such as identity or privacy and trusted execution and then there's Ron as well which yeah so the board why don't you say who you are I'm Ron Resnick I'm part of the EEA the executive director who's speaking tomorrow so I come from the telecom side and so I have a talk on Friday that we'll talk more about a roadmap so I'm not going to address that but just real briefly as a board and I think this is really important the board empowers a team and so that's the main qualifier the board folks are all they all represent their own companies they have a fiduciary responsibility to be neutral it's very challenging to do that so they try to have somebody neutral so we're employees of the EEA so we're basically neutral trusted folks who don't have a business interest so I think that's really important to acknowledge and that's the main point everything else you guys covered is fine so they our responsibility is to run the day to day operations as a team the board meets once a month and we fill them in they don't like it they boot us out they like it they keep us great thank you Ron so that there's a question in the back yeah I have two questions actually the first one is the what is the role of EEA when it comes to implementing the blockchain protocol with enterprises do you actually supply some developers you have a team to supply to these enterprises interested in doing some POCs with them or do you just connect with other startups who's actually doing it and then you just build a bridge that's the first question can I answer that and then get the next question is that easy we don't have a team of developers we don't do the work we're members of EEA and that's what they do so members as in the blockchain startups yeah companies who are making stuff or doing consulting or running tools building tools so that even includes JP Morgan's quorum team who created the client quorum implemented and yeah those folks might so if you go to EEA what EEA itself gives you is here are the standards here are the specifications that these things these clients should conform to and because it's a place where people are interested in actually defining together those agreements there are the implementers people making clients customers people who say well I'm going to want to pay you to give me a client and here are the things that I want to make sure it can do and so I'm joining the conversation because I want to make sure that the standards actually mean I can get a client and not only is it interoperable but it does useful things because the customers say these are the things that need to be useful and then there are consultants and people are in sigs because they really just want to learn but there are also people who are I'm a consultant in this space I want to put in my two cents worth occasionally I want to meet other people in this space in the enterprise space because all these buyers are coming into this forum and I'm selling so it has more of a an informal role as a marketplace that you can go to but EEA itself doesn't do any of that we work on the standards and we work on the special interest groups where people set up we want to know about what things are important to us as real estate people where are the vendors, what are the products what are the ideas, what proof of concepts are there and who can I get me who can I go to build me one or I'm a builder and I want to find real estate people why don't I come and talk to this group and a key aim when we were starting really was saying what's the delta between where we are versus getting to something that can get to production we're sort of in this proof of concept lots of things being rolled out but can't get to production basically because of this perception and reality the Ethereum based systems they're not finished yet you're not going to get support they're not going to be standardized you're going to get implicitly vendor locked so really wanting to say here is a specification if you start using something based on this specification you're going to be supportive you're not going to you're getting a higher grade really so you had a second question as well yeah my second question is so EA is part of the ISO so that you may also mentioned about the standard you do advise on the standards as well so do you have anything to say about that part or I know this session is more like depth X related or we can actually have a talk after the session as well so EA participates in ISO ISO has ISO is the international standards organisation this is a treaty based legal thing where basically countries go and vote on standards so and they make standards for all kinds of stuff ISO 9000 management standards about how to make sure you're doing a good job of managing your organisation and ISO standards for making sure that cameras work or seat belts won't break there's masses of these things yeah and date formats is a really good example at this point ISO has a date format standard which I've never read what is date format how to format a time and a date it's called ISO 8601 and I've never read it largely because I know it is a big fat document and it costs like 100 bucks and I'm like I don't need all of that I know a lot of the stuff in it ISO makes standards fairly slowly as a rule there are some groups that work quite well and there are a lot of groups that work very slowly and the final decision making process of ISO is every country in the world basically has one vote and so you know you get literally some country has something they want to standardise for some reason or other and they go and find a whole lot of tiny countries who do not care at all about this thing and they pay them to vote and that's how these decisions end up happening in some cases so the benefit of ISO is there are a number of countries and a number of legal areas of work where people say it's got to be an ISO standard or they say if this is an ISO standard then the government pre-approves you doing things or companies will pre-approve buying anything that is ISO certified something or other number the EEA I think our basic position is like many like W3C and IETF and Ethereum we work on rough consensus and running code we're interested in making standards that are useful very soon for people who actually need them and being decided on by the people who need these things to work and really I'm not sure why ISO wants a blockchain standard beyond the fact that they want every sort of standard there is ISO standardised and ISO standardised HTML there is an ISO HTML standard there are precisely zero implementations of this standard in history like you literally cannot get an HTML browser for the ISO standard that you've ever built just doesn't exist I think ISO standardised how to make a cup of tea I think so I believe the ISO standard for me it is probably rubbish they probably do the milk wrong around there I'm curious about what conclusions and what consensus what kind of ideas you came to two days ago were you thinking gathering at the Council of Prague with magicians and with the EEAs individuals and the discussion was about EEAs involvement with the IPAs I wanted to take that basically that topic and the question about do we envisage disagreements and say I don't think we envisage disagreements I think one of the key underlying principles of the technical work at EEA is we're based on Ethereum essentially we can't afford to disagree in a way that creates a hard fork we may not use a different piece and we have to work out how you do that in a way roughly which means when people build a client so Pantheon Pantheon runs on mainnet Pantheon will be an enterprise client if we make requirements where Pantheon has to choose one or other of these things or or any of the clients that would be stupid because why would we do that if we're a little bit more thinking and we can make sure that we're actually compatible and the big win of the compatibility is we get clients and as I said at the beginning you can go out and hire a developer and they know how this thing works because it's basically just Ethereum I think if anything it's the other way around something I envisaged at the very start was actually the fact that the EEA was doing a clearer would actually be a means to drive to more canonical specification on the public network where there are areas of ambiguity where that's kind of been okay in that scenario but it isn't on the enterprise side you need to get to clarity with something like the RPC being a key point That's exactly the example I want with the RPCs they decide like clients decide as they implement what are the real set of RPCs and it turns out that this is basically public Ethereum stuff and we're writing it down inside EEA for the things that you have to do inside EEA probably that's a thing that we should just be contributing back to the public community having done all that work we should just give it to you guys so this was, I think Jamie was kind of prompting for this so we had a session at ETH Magicians covering ETH and EEA is Eric from Infura in the room? Eric, Eric too I'm unsure since I haven't met him in person yeah I think you just left so this has come up multiple different kind actually I'll clarify something around and other people can jump in and correct me as I understand it so there's the Ethereum yellow paper which describes and is the specification for Ethereum that's correct Asterix it turns out that not everything that you need is in that yellow paper one of those things is the JSON RPC interface as Geth and Parity were the two leading clients and they kind of disagreed and there was no solid spec they have slight variances so you need to choose whether to be bug compatible with Geth or Parity and each of them kind of disagree which of the other ones is buggy as we're moving from two to N clients some of which are also enterprise Ethereum clients it turns out that there's a lot of work of specifying those things and testing whether your compliant needs to be done Infura which runs lots and lots of client nodes is one of the people that really feel this pain on new releases they have internally written some JSON RPC integration tests that are across client I have started discussions with Infura about contributing those integration tests as a public validator and yes, please so we have a thread on the Ethereum magicians will announce public calls and I think this is going to be one of the test cases where public Ethereum and enterprise Ethereum will really converge and work together on this and then more broadly in that discussion we surfaced a couple of other different things so JSON RPC watch for that that was actually one of my slides at the launch event of the EA was that specific use case perfect, perfect, we're 18 months on maybe we'll do it yes, yes, exactly something was brought up by Dan who's in the room here was asking about if right now when you contribute an EAP you need to commit the context of the standard to the public domain what so that covers copyright what it does not cover is anything relating to patents so there's a danger that clients and other implementers could implement things that are patented so patent trolls might attack the Ethereum ecosystem so this is another thing that enterprises are very concerned about so they get that very clear so there's work to be done on that issue, this might be something that first we need like a human to guide the process and secondly, likely some funding to get legal advice and perhaps a group of people speaking to the EF and other funding bodies to help get that done so we've posted that as an item that's going to be followed up on just to mention the EEA has a both a legal industry working group and internal legal consultancy and a patent policy and the EEA it's already clear you come along you leave your patents at the door and agree not to use them against people and bodies like the W3C and IETF have had various policies around this as well so finally on the EEA side and on the special interest group side Charles and Alex have agreed to go off and talk to all of the industry groups and get a short list of hey, here's some stuff I'm interested in that may make sense to move through the EIP process so again, more flush out even pre-EIP saying here's some possible working groups who's out in the open and wants to talk about possibly standardizing or specifying some of these things so really we're looking forward to seeing what that looks like something that I actually want to mention at this point and I apologize but we need to kind of get a lot of this into Charles' brains is Nick has a day job he works on ENS, he's paid by the EF to do various things he volunteers to be an EIP editor as many other people volunteer to leave comments or do other things like that Brooke and I have started some community calls where new EEP implementers can come and talk about it so a lot of it is just throwing it out the flagpole Jamie does an excellent job of parsing through interesting new EEPs and pulling discussion together and saying hey look at this so these are all roles that are sort of emergent that are happening none of these things are the Ethereum community there is no the Ethereum there's a set of processes that we agree to kind of roughly use that is one of the difficulties with many corporate entities that are there for an entity that they can interact with the company, the Ethereum company exactly even the Ethereum foundation is not in charge this is a developer conference put on by the Ethereum foundation it is not the developer conference Ed Khan in May run by a group somewhere out of Asia that themselves are a non-profit Ethereum community conference that happens last year in Paris and I think is going to happen this spring again in March so we are all Ethereum is the word that kind of happens here and also none of us are because none of us can speak for it there is something else I wanted to add as well just through some discussions that we've had with Nick too and in other ways that we can work together is using working groups as a way to disseminate information about EIPs that are actually in their final sort of draft stages and telling members these EIPs due to be finalised shortly it's definitely worth commenting on them or feeding into them because again there is I think that perceived problem that was spoken about earlier where people don't know where to start with it but if we use the EAs a vehicle to get people across them I think that's very relevant because especially like the core EIPs and the networking ones and so on they're very likely to be referenced in the EAs specification down the line as well so that's one area and then another area was whether to have a surprise ring within the actual Ethereum magicians as well so that again becomes a way of ensuring that the information flows from within the discussions the magicians are having back into the EA too so I think those are some other initiatives that we think could have some good traction as well So one other piece of the EA thing is why haven't we done this yet and the answer is well we haven't done it yet but we actually have a process inside the EA today where we can say this is how the EA members bring something back into the world we do have a lot of members who understand that that's a useful thing to do we have an understanding amongst a lot of the people particularly participating in technical work where there's stuff that we will do in the future because for example it's not that important to mainnet so the mainnet implementers are not going to be excited enough to do this on the time scale that enterprise users want they'll develop it in EA and some of those pieces we think will be interesting to mainnet over time and we want to work out how do we take those pieces out to mainnet and then we can do the discussion right now discussions are in a private repo coming to the public Ethereum community and saying look we have a solution and you all should just adopt it because you'll love it doesn't fit very well with the Ethereum philosophy and doesn't work very well in practice I think there's there's something interesting to note here where like Ubuntu and other Linux distro LTS long-term support addition in some ways as Charles was talking about timeline it's actually the reverse Ethereum public mainnet is kind of like LTS it needs to be the hardened, conservative completely adversarial environment so enterprise likes that because if you're looking at it it'll probably find from it's bulletproof things so an interesting thing that both DFINITY and COSMOS said in some of the kickoff meetings of the EA was that one of the main reasons they were looking to launch public networks was because running their consensus for an extended period in a public network is the best possible proof that you can have to show that that would work in a low-bearing enterprise context here you go all the attacks in the world can go at it and it's still fine I think it'll work for you I would just want to poll for questions we're coming up on I think we have about close to a half hour left any particular questions that people want to dive into right now I wanted to ask if you can step-by-step explain your internal governance process because we've heard there's a board and there's meetings but how does it really work step-by-step it's top secret of course Ron, you should probably explain that so you asked about ISOs I come from other standards orgs and I've seen how they operate from Etsy and then there's a 3GPP partnership project which is more of a they're the guys who actually write the spec and Etsy rubber stamps it for telecom and that's how you get LTE and then I've got a lot of years of experience in the IEEE and so we're trying to pattern ourselves to be similar to how those kinds of operations work so I'll share with you this will be part of what I talked about those organizations are all based upon and you're talking about IPR and patents and that world is called RAND reasonable and non-discriminatory which means that there's a royalty the world that I joined here there isn't any so it's been real interesting to see how we balance the two and so the governance though is similar to an alliance so I'm familiar like I don't know if you guys are familiar with the Wi-Fi alliance open mobile alliance and this open connectivity foundation we're like that so that gives us a little more freedom than an ISO like an IEEE which you can't do marketing but the Wi-Fi alliance or our organization we could do more and so we're really not an ISO and if we did we'd have far more stringent requirements to be an ISO but we're an alliance there's a board of directors and that board of directors hires a management team and actually Ethereum Foundation did the same thing I is an executive director she works for the Ethereum Foundation so there's a management team and so I ended up getting that role and so that team then and so we have to bring on others so the membership fees that come in from the EA it's a not profit it's called 501c6 so we're not a fundraiser we raise a revenue through the management fees and then we spend it for the betterment of our members so all our job is is to support whoever is a member we're just we drive along the direction that the members want with guidance from the board so basically whoever the board hires the team and these guys are all part of the team then we put together our objectives, our roadmap for the spec what we want to do to create value for membership and then we try to execute on that and all we do we write specs and then the one thing we left out is in the world I came from there's a certification program so the philosophy that I see us trying to do is harmonization of a global ecosystem so I'm a personal big fan of doing that so I'd like to see that kind of model come across so we can deliver and you guys have a different definition of interoperability the interoperability that I'm used to is there's a spec that these guys working really hard to deliver and then we have a certification program which we will do starting at first part probably in 2020 anyone who develops a client will submit their solution if they want to use our logo to certify but our spec is freely downloaded anybody can develop, they don't have to be a member of the EEA and we're trying to do some more to create more openness and Charles and I I can mention that if you guys are okay with that so these guys are pushing me because I come from another world, a closed open organization but to accommodate the folks in the world of Ethereum we're going to open up through the github the opportunity to see the work that's being done in the EEA you don't have to be a member you can make comments and pass this along even though we're going to do more we'll promote this you can make comments and then you can and we'll take a look at it but if somebody want to make a formal contribution they would have to be a member because they vote and so there's two things you have, members have a vote on the thing as I said there's a patent policy members when you contribute something you've made a commitment that this is not going to be you're trying to sneak stuff in so that you can get a patent license so if you put this in you give it to the community for free does that mean that an outside contributor could suggest something and then someone from within the EEA with membership can champion it and basically put that on that is a potential risk this is a known that's a risk that happens everywhere no one's ever solved that yeah it's not I don't mean that as a problem I just mean that that's a benefit actually here's someone with a good idea well great so the specific risk and this has happened in reality is company A goes and files a patent on something person B out in the community says I've got this great idea you should do this company C which is a member puts that into the spec and all of our implementers go off and implement it and then company A writes a letter and says since I own the patent here are my licensing terms because I didn't make any agreement because I wasn't the one who put it there and all the implementers get hit with you know a few hundred grand worth of legal demands and we do not want that to happen this is why we said the magicians thing we would like the EIP process to have more robustness in the way that we've got to try and protect against that situation but I mean your ABC there's no defense on that in general there are holes in the system right you can fall down but having at least some fence is useful I just wanted to ask how voting actually works so that was what I was going to say the voting actually works in the technical group as I said on the basis that if we have to take a vote if someone calls for a vote there's not enough agreement yet and so we're not ready like who makes the proposal so something comes up somebody wants to add something to the specification either from a special interest group or task force or directly from the client spec working group they raise it as an issue in github and then they basically people discuss it and then at some point there's a pull request to the specification people comment on it and then during these calls that happen twice a week every week basically and it rotates on time zones people basically discuss the proposal there's an opportunity for questions and basically if people have any formal agenda that goes out you've got a few days to check what's being actually proposed for agreement you can say no no no no no stop and that means we haven't got there yet we will go back to it any member can participate in any group so if you join up you can be in all the sigs you want you can be in all the working groups once you're in you're in wherever you want to be in and that call is basically the final opportunity for anyone to raise any final blocking objections and if there is a blocking objection it's dealt with accordingly so in the formal governance model the spec still has to go through the board the board could say no wait this is crazy in practice the board has then got to go and face the members and say why did we throw away the work that you guys did so they've got to have actually a decent answer that says because it was crazy we have not exercised that process because fortunately we haven't yet done anything that stupid I hope we don't so this is what I wanted to add is that I believe there is a formal voting process the reason Charles is not describing it is because we don't ever intend to use it it has not been used we're basically working very hard not to actually ever get to such a process so yes there is one but that is not how the group is operating on a day-to-day basis at all we will have straw polls and we will test whether we've got consensus but if we haven't got consensus we don't do stuff which is a higher bar than a vote so we don't need the voting process because we already do something that's tougher so you don't do humming you don't do humming then we don't do humming because it doesn't work very well over email and it's kind of hard to hum on github but we do do thumbs up on github comments the consensus test is first are there people actually supporting something and then you have to say I got a proposal and no one looked at it and so it went in people have to be supporting this thing and agreeing and then you check whether anyone says no, no, no, stop the votes I'll teach you one of the specific issues so we can see how they work in practice between EAPs and EA how they would participate on the ESPEC we had an issue open that says we should support whisper but in the end there's no spec for whisper so how would you go about working together to have a spec for whisper how does that look like I'm just going to redirect a little bit on this the way that it is phrased it sounds like there is an EEA which is a true statement because it's an entity an anetherium except there's no anetherium so that's the tricky part in this does anyone want to talk about how that might look like from or perhaps the EEA has some questions for some assembled anetherium individuals of how that might happen I mean specifically actually with whisper and devP2P they're very they're good points to bring up just because the way we are in the EEA anyway is that we use the term clients should implement whisper support it's not essential to actually run a client and run a network but at the same time it's kind of a standard that's used that's been established within the public anetherium ecosystem and what we do around the actual reference points for the implementation it tends to be pointing back to the relevant wiki pages the EIPs potentially but it's really digging around to see what we can find that already exists that's kind of closest to a specification so sure in an ideal world it would be that if there wasn't something we'd be able to write something also someone would but in practical terms it just takes up too much time but so what we find is that we're linking to a number of different sources for instance as well with the V2 of the spec we now specify the eight different pre-compiles that clients need to support those eight pre-compiles are defined in the Ethereum yellow paper and so the spec actually points to the section in the yellow paper there so it's really about us aggregating the best sources we can find and then referencing them there now with devP2P this is something else that we want to have as a must in the spec for devP2P technologies and Ethereum 2.0 is obviously looking at libP2P but realistically for 1.0 clients that's really the sensible mechanism to use and it's the most tried and tested and there's right now we don't really have the definitive version of it for that and so we're again digging around but it's kind of as each case comes along really we're just looking out there to see what there is that we can point to the reference but it's certainly not foolproof so as I said before we don't have a process for this yet we would and we can't force out any more than that the open Ethereum world can force GIF to do something it's like we can't say that again I didn't understand what you just said there you can't like force GIF to do something and speaking to internally at EEA we have the same situation we can't force our members to do something so we don't have a policing mechanism we're aware that we would like to have a better spec for whisper has that been signaled publicly anywhere? it has not been signaled publicly yet because we don't have a process for doing that either but coming here is part of how do we work out that process and one of the key pieces is how do we build a process in EEA that although there's no you guys we're all you guys and we are you guys too how do we make that work in practice in a way that is useful to the outside EEA world because it's how would how do you do things like form new working groups in EEA so that I was there was originally a process for there was a governance committee and there was a form you'd fill out for a kind of working group you wanted to create it would get submitted to the governance committee we'd take a look at it and make edits pass it back and say you know this scope is too large or it's not clear what industry you're doing and then it would get basically approved and then get into practice right now it's basically whether it's a SIG or task force document and scope sort of thing but it's basically just approved by Ron the executive director and the board does the governance committee still convene does it still exist maybe your first step is to spawn the governance committee so that's the formal mechanism is that the board approves this right the board approves a group in practice for a lot of the stuff they delegate that job to Ron and they say you know you have a look at it approve it or not if people scream they'll scream to the board and the board will come back you're saying it was amorphous you're saying it's amorphous but then I hear that there was a governance committee and there's potentially even something even more clearly like leading leadership it doesn't seem so amorphous to me it's not so amorphous the point I was actually making is that outside Ethereum is kind of amorphous outside enterprise Ethereum that the rest of this world as Boris you know doesn't have like you know a formal shape we can't go to the Ethereum and talk to them as enterprise alliance comes to Ethereum if internally inside the EEA you can say well you can come to consensus you can make a decision however way you do it that we would like to collaborate on whisper advancing whisper standard I'm sure that you can get the whispered devs together in a ring or just independent of magicians I'm sure you can make that happen we can and we should and we need to figure out how I really want to inculcate we're a member driven organization the members rule in our organization our job is to minister and help facilitate the direction that the members want board members are have a at the highest level they can vote or say yes or no but they I can tell you they're not that involved on the day to day operation so how how we're set up for establishing a working group or anything at least I encourage the members to approach they can approach any one of us and this happens all the time particularly in our special interest groups it could be what you just talked about any kind of work item if it was a work item so we just talked about it so I'll give you real stories we've talked about a test net so we just met yesterday and we decided we should form the best way to do it is a test networking group and then what we'll do is they'll write up a proposal and it's the members who do this so to what you said it's ideal it's the right way it should be done the members all get together write up a proposal and then somebody's got a champion I think same thing are there I guess potential champions that would I mean who do you see in this group of members that would find it most interesting to collaborate with the greater ethereum community let me just redirect a little bit because I think I want to use the flip your language back at you because I think I've discovered the key to this so what I heard Connor say is yeah we kind of cobbled together some wiki pages because there was no whisper spec and same for devP2P so does that mean there is no work item that directs EEA staff to make a better spec yeah EEA staff don't make the specs right okay so there's not that many of them yeah we yeah we do as I've described is that the correct language to use it's good enough we can go to the members and say and your question is spot on it's like who is going to be putting up the effort to define whisper and the short answer is until we've put the question and got the answers so propose a work item is that the correct language we would propose a work item sorry someone in Enterprise Ethereum Alliance a member or a staff member would propose that we do some work on this and there are two things that we could do one is we could propose to set up a working group inside Enterprise Ethereum Alliance where we set up this group and following our current process we come along with the whisper spec and it's all done really wonderful here you are another thing we could do is say well actually this is a thing that's been developed already in public with some Ethereum the Ethereum philosophy and maybe we want to do it using the EIP process maybe we want to do it just by talking to a bunch of developers we would in person would actually write email to the members list and say hey members or hey tech spec working group members we all know that there is a problem that there's no good definition of whisper rather than standing up an EEA working group inside EEA because this is a public piece of the infrastructure we the people who want this thing should go into the public space where it's actually developed and do the work there I think in general I would encourage you all to write this down publicly as the EPI for the EEA so that those of the outside know how it works I'm going to add one other thing that we're doing now and it's called an associate member program for other organizations or entities so we've discussed with Aya to have it's called an associate member and we want this to happen the Ethereum Foundation the management team can be part of the EEA and be a member we also talked to Bob yesterday about Nick about doing the same thing with the Ethereum magician so I'm picking up how do you get something externally to be able to have even more visibility and participate and contribute so we're an open organization and so we're trying to encourage more of that so that's another way but I can tell you because I get the emails if I had anyone say oh why are you guys not doing whisper you don't have to be a member and if I would bring it to these guys and say this is how it works because I'm not the hardcore developer I would take it to these guys and if they said this is something we should do you don't have to be a member you can send it in our way so then we do this bug passing thing where I pass the bug to Connor and Connor passes it to Antoine you know about this go do it hey Boris yeah please I want to talk more of a macro philosophical level for EEA you're talking about the majority of your members the majority of the members enterprise, corporations, governments or is there like a small companies sure there's obviously EEA started out through not the ethereum foundation but the ethereum community to give a say towards the enterprise and government community where does EEA currently sit in evangelizing the ethos and the philosophy of ethereum where's the line sit between the community and enterprise and has the enterprise and the governments resonated at any level of the philosophy and they just kind of want their stack they want their kind of usable interface and usable products and then kind of leave I'll just speak to so I don't do this as much I still participate in the EEA from a kind of like volunteer organizing perspective trying to help basically I like hop into certain groups and encourage people to share more encourage people to work with each other more and all these other things the social catalyst that doesn't happen to the ethos thing I think a lot of organizations so also a little bit of background prior to this I was at a think tank where I was working with groups like Procter & Gamble Walmart, IBM, Cisco Intuit, whole host of groups on what they thought the future of blockchain technology in general would be and getting them together with entrepreneurs who were actually building this stuff and you know devs who were even we would bring in people who would consider themselves anarchists I think that most organizations have had trouble kind of envisioning anything other than just kind of like a small consortium or you know accomplishing their immediate needs from like an operational standpoint but I think over the course of a number of months we started to see groups say like oh no wait a second there is this broader public ethereum like vision and they're starting to realize they're coming off of a lot of like isolated island private nets to say there's so much more usability so much more of a community so many more developer tools and this opportunity to actually participate with other people and share their assets with other groups who can use them pool data pool you know information and things from these groups they want to play with the broader public ethereum ecosystem and that's why I think it's really important and we're trying to groups like I mean me as an individual I've been trying to push people to say you should be engaged in sidechain research you should be engaged in actually you know working on all these technologies for public net because it both achieves what you want as an enterprise for privacy and sort of standpoint but also enables you to actually join everyone else on the on this kind of broader mission of like you know big like web three just continue the question is there a way like because like I know that there are a lot of working groups and they're doing something is there a way to get the holistic overview what are the groups doing where to get this information because like okay honestly I'm subscribed on all these news letters they provide like a lot of controversial information it is not possible like to get any understanding of what's going on and basically I can easily get one not easily but an easy year to get what community is doing but for EAA is like totally like here there and you have to look to the news of the particular corporations what are they doing is there any way to get that structural because for the whole broader ethereum community it would be really nice to understand where actually those enterprises are investing what are they doing what they're interested in because there are like some fragmental specifications but not like the roadmap is not clear at all and especially between the working groups yeah I think I think so I mean just I'm again speaking as a person and as a member of consensus as a person I made the joke earlier corporations are people too which was pretty funny in the context of it like I've I felt like EAA has served like an immediate kind of functional need for organizations to get together and talk and to form specifications for them to start using clients right this is very kind of like bare bone stuff and a lot of that has been they needed to talk to other enterprises but I think it's very clear that in order to get the most value out of why they got into blockchain technology to begin with to start integrating with the rest of the community they need to have a cohesive or sort of structured voice that's available to others and for them to be able to call out for help for them to be able to express what they have in abundance that they can share with the rest of the community I think it's not just a marketing thing it's not just a snippet share thing so I think that's something that we want to develop and actually help foster I want to answer your question the short answer is not really there's a lot of stuff there you can get a sense of the shape of things so you can see that there are a lot of sigs and there's a list of sigs if you want to find out what's happening in those sigs you sort of got to drink from the fire hose because if you're not drinking that stream of fire hose you don't have a real overview and we don't have the bandwidth of people who are drinking all the fire hoses and distilling it down and that's kind of unfortunate it's probably also fair to say that our systems, our website and so on are not that good and we know that improving that and making it easier to find stuff and making it clearer is a kind of important question what basically means that all the parts are making advice you know what's kind of funny is Boris Boris has kind of get driven ego death in me he's like there is no it's like hardcore existential journey it's the same honestly with enterprises enterprises have different goals, different needs and they're just starting to form that so there is no enterprise goal there's no grand plan here right there just isn't a grand plan because there's not like a bunch of people they're building a death star we can finally reveal it the EEA is building a death star on Ethereum thank you very much so one of the things that we were so effective one of the things that came out of the discussions earlier with Eve magicians is that Alex and Charles are going to go off and try and source a list of likely items that may be submitted to public Ethereum and I think that's the next deliverable we say I want to go over other things that we surfaced what we said here in the session is we would love to know what the API for the EEA is and let me state it correctly a URL that we can point to if someone asks we say go here and that's the latest snapshot of it there's a desire to do more work together I think to go back to what you said about the philosophy of Ethereum that is more likely to happen on the outside I think Alex the individual is interested in pulling from some of that and bringing it inside and vice versa I almost think that what you brought up before about an enterprise circle may not be a correct thing I think interested people going into the areas that they're interested in one of the things that I was also surfaced that I checked and we forgot to mention is that Snarks or ZK Snarks is there is some stuff being worked on from an enterprise perspective that could very much work on mainnet I don't know if it was an EEA member or not that released something on mainnet and a lot of this is as the EEA evolves its processes that on the public side we get clear of resources and everything else so I want to thank Jamie for putting this slide deck together it's actually in a repo that can be forked and you put it under an open license I think so that process is something I hope to have this same presentation either the EEA only version or the EEP version keep happening and keep being distributed this force, this was the shelling point of vaguely getting our act together on some of these things all of the wheeze, right Alex and there's sort of a commitment between a lot of individuals to keep more working together watch ETH Magicians I'll tweet about it but ethmagicians.org is a place that you can find out more I've added an EEA tag so anyone can tag a topic and so there'll be one link where anything that's related to the EEA actually will show up on all the new items that is it I want to say thank you to everyone for participating in a very open way just thank you so much to the magicians and the broader community for inviting us to learn more thank you