Notes from Fabric Discussion 23-JAN-2017 morning
notes from Sharon Cocco (weeds):
----- Today January 23rd, 2017 ----- weeds [06:32] A few people are meeting to talk about the status of the Master code base. I am slacking the information as a result- this is real time discussion [06:35] There are multiple lists on the board-- these are all the stuff we want to walk through and determine where we are specifically-- TLS, validation message and TX, replay attacks, replication MSPs for gossip, anchor peers, channel leaders, HSM (key generation), chaincode return object, chaincode endorsement policy, revisit events, chaincode life-cycle (deploy/init upgrade,.. and policy), ERror handling, bootstrap with pre-defined channels, custom TX, CLI accepts multiple peers, application crypto library, system Chaincode refactor (location) and Chaincode calling chaincode [06:36] For SDK- (node.js, and Java)- Java only : create "official"branch, events support (example: rejection in blockchain), chain join ( creation basically done), REST wrapper, anything left in MSP, Java Chaincode, TCERt private key derivation, query on ledger [06:38] For SDK- add RSA , escc, vscc [06:40] For Docs- high level overview- ferris; technical overview- Josh; remove version 0.6 material; docker compose- 3 configs; ordering configs, CA configs- Keith ; APIs- Jz, SDK- JZ, policies- Murali; channels- murali [06:40] For Docs- end to end Barry/Ramesh [06:42] For Fabric - CA: Docs- API doc /swagger; readme; read the docs,... CLI simplification; TCERt- BCCSP integration/. option 2 (HSM friendly) support; HSM support- BCCSP or lets ecnrypt PrSCH; BCCSP for auth. header; Intermediate CA support? ; Test [06:42] For BDD- RSA, P384, Deploy CC, Mutlichannel [06:42] That is what is currently on the board... [06:43] Binh- let's quickly review this list and anything else we can add on, but these are the items that we want to target for alpha for the end of this month [06:43] (items are being added that I will try to add here) [06:44] For Doc- Couddb/ledger- Dave [06:46] For Ledger- finish couch Miscellaneous items (versioning, deletes); Query expose to application chaincode; history of key values(level db) - add to QSCC, expose to application chaincode; Chaincode examples- table replacement, query, history [06:46] for DOC- Gossary of terms- Nick, SCC- Murali [06:47] ----------------------here is where discussion has started------------------------------------------- [06:48] To original list- experation of MSP certs [06:50] what else on the list before we go through? (binh asked) [06:50] Gari suggesting we go through first pass and eliminating pieces we should not go after [06:51] let's do the list starting with TLS first and then Ledger, then SDK, fabric CA and whatever we decide will effect the docs [06:51] TLS- the server side works and you can dynamically add certificates to it incrementally and that's all checked in---- Under BDD we added TLS [06:52] Validation of messages and transactions- this is Ale's items, this is almost done [06:54] Replay Attacks- Angelo indicated what we have committers check the transaction id is duplicated- only the committers, but we have to generate the transaction id, which we don't- so we had long discussion.. we agreed to generate a nonce and generate with creater's id and hash that.. that part is important. whether we can create the replay attacks or not may not be completed [06:55] The discussion we had with murali is what if legacy software is using for application related- so generating for nonce of creator might not be accepted. [06:58] Today- we need to solve replay attacks and mine the transaction id to the identity of the creator. We need to use the TX-ID generator- this is equal to the creator plus the nonce.. this has to be done prior to preventing replay.. SDK is already generating a transaction id,.. but it's not done in the way that is highlighted here. There as to be an adapter into a question- some event comes out- you call api and you can map the transaction id.. if you want to track it- pass it in as a parameter. The question is for doing it- if we are going to be consistent on the SDKs and you agree and creator + nonce- it's not a hard piece of work. are we going to do it or not? We do generate an ID today... the id is nonce so we have creator [06:59] we will not do this for end of the month on transactionj id generator- creator + nonce [07:00] Replication MSPs for gossip- basically we formatted a final document at end of last week, we need to close some edgers, but if enough time to talk with Elli, I will like Gari/Binh to review and after that- we can finish this out [07:02] Anchor peers- upon channel creation, anchor is there, and we checked manually it works. I hav enot seen code that deels with configuration of stuff in peer when new configuration blocks comes from ordering service. and the adjacent manager config transaction is not in the peer. Jeff added that yesterday in BDD... he added the anchor peers in BDD. BUT we don't have a configuration handler on the peer side- without that, we can not deal with the configurations that are not associated with channel creation..... We also need to do extra work in the peer. We need to combine jeff's work. [07:03] Board changes- Anchor config block with handler; BDD [07:03] Channel Leader- basically the code that elects the leader is inside and has been merged since beginning of last week. the only thing missing is plugging into gossip. I have a chainset that I need to code review for this [07:04] HSM (key generation)- Vlad said we need on key derivation... our proposal is to remove this from end of January. ashutoshkumar [07:05] last sentence is not clear. weeds [07:07] Chaincode Rerturn Object- We have a merge conflict and Murali is checking it right now.. we need to leave this here, but it's pretty close . WE are returning an object from protos that we effined a long time ago- now we are returning an object that we are returning code where we use HTTP return status code where 100's 200's 500's and a message in there and a payload (which is a byte array). This gives more flexibility for chaincode to return what is needed. If you ask me to endorse something and I need to kick off a workflow- I will return code saying incomplete,etc,.. ; SDK list is being updated [07:07] SDK: added Update CC return object [07:08] @ashutoshkumar we are making decisions on what we are going to get done for end of January for our Alpha/Beta code- we will not try to tackle completing the HSM work is the net. Clearly if open source team has it complete- we can relook at the decision, but we're trying to make sure we prioritize as we want to get very clean Docker images and compose scripts for members of the community who want to program and play with version 1.0 [07:08] I'm currently taking notes on the discussions here on what we should focus on among several people in community [07:09] (not everyone is attending, so we are going to be looking for feedback to go to @binhn .. this is a first cut proposal) ashutoshkumar [07:09] thanks @weeds weeds [07:12] We need to add some additional work on chaincode return object- the remaining work after we merge this latest piece is to take the work Jim has done and completing it writing it down to the ledger. Why would you write the response down to the ledger? Not in the state base, but we would write in the transaction, so we can record the response code. We store events from chaincode into the ledger- so the worry was that we are getting all tehse responses and we are not saving it or persisting it. So it's not in the signed part of the block? The events are not in signed part of the block- yes they are in signed part of the block. Is it important to persist this information? If it's part of transaction and app is using it to make decisions, then it seems like it is important. In the query - we never send that so it really does not matter there. So if transaction id- what was the response? that one piece of information- we store everything in transaction, that could be important for auditing like chaincode events... Added "Transaction proto should contain repsonse" [07:14] Chaincode endorsement policy: what kind of policies are we going to provide? My understanding is that you can specify bv VSCC in lifecycle chaincode- if you give complex policies- code validating is there... the code in CLI/SDK is not... you send request, at time of commitment, the code is there to query the lifecycle chaincode and to validate that all the people are signing off. Are we using same policy that we are in protos? We use one policy specification that Jason defined. When we complete whatever work in runtime and by specifying in SDK and SLI- that doe effect the SDK which we titled ESCC/VSDD.. When you do specify it, you have to serailze it into Jason's format. We should do this by Alpha. [07:15] We need to check back with Ale on this [07:17] Revisit Events- this is from Pat (community member). we need to do events from chain channels and hook it up for channels and hook it up with MSP. So we added Revisit events (channel &MSP) We should add security restriction because he's not authorized.. depends on how far we want to go. We need to confirm with Pat. @pmullaney We need to check with Pat and verify with him if we need to specify any additional policy or we use policy from the channel. The easiset thing is if we have read permission on channel, you get events. Based on my experience on how fast it works- the best we can hope for- backend he has chaincode and block events.. and he's working on SDK. i don't know if he can get the rejection events in and support for SDK. WE don't need rejection events. In 0.6 we had this- because invalid transactoins were not part of block- but now they are part of block and we have bit array that marks invalid transactions [07:18] We do need to add the channel ID-- we don't think we will be able to do any security on revisit events in 8 days [07:18] You have block come in- list of transaction. if they fail in MVCC/VSCC,.. we still add a bit aray filter that points to location of which ones were invalid. Basically means that we did not process a state change [07:19] We do have ability to check for false/invalid transactions. that is always just there [07:19] Do chaincode events get set for invalid transactions? Murali says today it is.. we should probably revisit this. [07:20] He builds in handler, the api that does it-- on the orderer side- it has to have the exact same logic of whether you are on channel or not.. and it will process signature from MSP list. When Jason/Kostas gets that code and we can take the handler code and use it for the events. Jason and Kostas and that team will be able to probably do that faster for Pat [07:20] to utilize [07:22] Jim Zhang said we need to filter out the events for invalid transactions otherwise it may be really confusing... it is absolutely possible. the simplest way is that fabric won't send chaincode events. block has chaincode events. and SDK will do the parsing. SDK is already doing that today. events by transaction ids.. so you move that , Basically Jim will have to map for transaction id- you find out what #numberit was in the ordere and you check in bit array. [07:22] We need to do post processing on the SDK [07:23] Do we have a size limit? i know we have number of transactions, but do we have a size limit-- we have preferred max bytes and max bytes. it's 512K that's the preferred. I know it's north of 7 Megabytes... we need to revisit the block payload because it travels through the events like that. Pat is actually filtering out the deploy transaction and removing that and does not touch the other stuff yet and we need to make sure he's aware. I would prefer only transaction ids and events, but then they have to go back due to security. [07:25] Chaincode lifecycle- do we want to redo the deployment and upgrade? We need to make a decision on this today or tomorrow. the policy is done- Kostas said he needs to ask Jason . this is chaincode policy who can deploy and manipulate the lifecycle when creating the channel . It is the deployment of the chaincode- who can deploy chaincode on the channel? We have some control on who can deploy and upgrade on the chaincode? [07:27] There is a proposal on how we deploy chaincode- and we need to decide. There are two parts of it,.. so we are highlighting chaincode life-cycle as a quesiton mark. [07:28] Error handling- we have the base, but everyone needs to use this. The base - we have code at the right place to encapsulate the stack trace.. if there is an error- and that error code indicates the components .. so you know this is chaincode error, or this is peer error, or this is orderer. The framework is done but not all components has used it. Peer has done some of this. - define error codes for component [07:29] Error handling is going to happen from now until GA honestly [07:29] (GA is a relative word here,.. but it's when the fabric is stabilized for production use, which is dependent on quality work being completed) [07:33] Bootstrap with predefined channel-- We have hardcoded in our code that we start up with a channel,.. but I'd rather do that as configuraiton out of the code. if we specify the configuration and we start it up with a configuration versus bake it into the code. In other words you don't create cli or SDK... you look at config- they need channel test id to start up and then we create it. rather than we have it in the code. This assumes that we have ability in orderer and predefine in channel and genesis block and use with the peer. We have to have block from orderer. The orderer has to start the config block and they need to know members.. We just need to have a default thing that people start with. This whole process is security based.. we haven't configured the orderers MSPs properly. . In our code we automatically create test channel-- that is the point. If that needs to go, we need to startup with channel for programming. We need to come up with dev mode kind of thing.. Easy to say create channel in peer, but I also need channel in orderer. This is where the complication is. The current feature will bootstrap system in 4 seconds. having a test id channel- the user test - i would just get rid of everything and it confuses everything. We need to come up with a way- a nice simple way in the bootstrapping feature scenario how we have a system come up for people that is working,.. and we can do that. [07:34] BDD has a lot of this weeds [07:36] I worked hard on this- we should not shortcut ever-- for developers, to bring up system, we can't tell them to run BDD. But we can make that easier to do. So what we want is a CLI to bring up a system for development.. jeff stated tweeksk knobs parameters is pretty complex 27 steps- and there is a tweek in everything orderer, peer id, the signers, the developers,.. then creation policy, who are your anchors... someone is going to write it just like feature file.. but our test could just be the script. This is a full blown interactive... WE are going to hackfest and we want people to have a simple way to do this [07:37] The test chain id has to be in orderer- and this is bad part- having hard coded test chain id in orderer is bad.. in dev environment, we need to prime it in dev environment and not hardcoded in environment. So we are getting in design discussions.. [07:38] let's take this off line-- we are going through this list, but we want people to do something on the 31st- orderer comes up and peer comes up- create channel api and I get you default certificate, create channel, and add one org and the stuff should just work-- that is what is a development system.. [07:39] ARe we telling developers that they ned to set up our system- vagrant and everything to run BDD-- NO.. Behave stuff only requires docker compose period... there are a million ways to do this-- so we want to get to prove this out and where this is consumable is to eliminate hard coded stuff and if it doesn't work, then we need to go fix it... [07:40] Bootstrap with a channel for dev- Jeff Garrat is going to do this and work with Gari/Jim... [07:40] there are simplist- CLI,. SDK .. the usre wants to do something more complex with BDD.. the test chain id we need to remove and make it simple [07:40] I worry about concept of having a separate network that is for developer mode- i think those days are gone. in that case you provide sample ceritifcates and run through the process. no more shortcuts-- [07:41] all keys loaded from files,etc,.. even SDK is doing that now... Jeff made important point there are 2 main places we are hard coding- test chain code id... certs was hardcoded- we still have a sample out there- we generate using bdd and this is directory or use directory already shipping [07:42] Custom Transactions- not for end of Jan [07:42] CLI accepts multiple peers; we need this to test endorsement policy [07:42] App crypto lib- this is a run at for alpha [07:42] system chaincode refactor- this is eash given Ale's work [07:42] Chaincode calling chaincode- we have addresswed the query case [07:43] QUERY CASE only on CC calling CC [07:43] Exsperiation MSP certs- we will not address this for alpha [07:43] ------------------------------------ [07:43] For SDK (node.js, Java) [07:44] The master is still on 0.6.,engaging with DTCC- we have created a 1.0 branch that we want to be master. [07:44] We are having to merge this. [07:44] Between DTCC and those on phone- there is also another guy from Fujitsu we need to merge everything [07:45] Java only: create "official" branch. #1 does not have to be done by end of htis month, but we do need to "clean" the directories up [07:45] and that is being worked on to ensure we have clean consolidation [07:45] Events support- Jim Zhang needs to talk about the eventing piece with Pat (see discussion above ) [07:46] Rest Wrapper- we have now handed off to the team that has joined the community in Hursley to do this [07:46] GRPC for Join is in there- Brett has committed that- but we have trouble with MSP definitions [07:46] it fails at that point- but we are getting all the way through the GRPC aspect [07:47] ChainQuery on Ledger- The api is available in GO code is there, but it is not there for GRPC.. pass through query [07:47] chaincode join- synce it's system chaincode call you can copy a lot of logic on query on ledger to complete this [07:48] Remove RSA and HSM for SDK goal for end of month [07:50] We have the Go implementationfor TCERT- we have the TCERT derivation form the last implementation is there. It takes a key derivation on the SDK side and it's exactly the same.. we can maybe get there and Gari Singh can help that [07:50] ESCC/VSCC- we need to add reference to a name in the proposal and we can do that [07:51] For query on ledger- this is just AP that you already call on channel join, but we are down to 2 1/2 to 3 developers.. on priority list query on ledger seems low. can't clients call system chaincode on any special thing on SDK.. they can also do from query CLi and get it weeds [07:51] Jim is probably going to x out query on ledger [07:52] SDK already accepts multiple peers (this was a question). [07:53] -------- [07:53] For ledger- finishing couch misc items (versioningk deletes) [07:53] Query APi is already exposed, but need to do work related to application chaincode- [07:53] WE are in middle of history of key values (level db) [07:53] We started doing the work on couch for history of key values and pushed down into level so that everyone can have the history not juts couch people [07:54] For couch- we do not support remote- we will only support local to the peer [07:54] Finalize QSCC block/tran structure that gets returned to client has to be discussed between Binh/Dave.. we definitely won't get through examples, but we may try to go through table replacement/query as we can before end of next week [07:54] @manish-sethi wanted to make sure you are reading the channel here- see all up above and start of conversation [07:55] maybe Mohan can help with examples possibly? [07:55] ------------------- [07:55] For fabric- CA [07:55] comments on the list from up above [07:55] Keith is trying to generate the swagger [07:57] We need to decide on whether we do something on HSM support or later-- I think we decided that we are not committing HSM for alpha but HSM support (BCCSP or let's ecnrypt) - the way i'm leveraging- i want to use BCCSP integration throughout and then get HSM support through BCCSP. there are multiple places for private keys- signing of CSR request, singing of authoization header, signing of TCERts.. thing that is where we need to do the integration. We already have BCCSP config integrated in. The thing unclear right now is can we assume if we have BCCSP integration then we do have HSM support or no? [07:57] Vlad is going to have to clarrify [07:58] We want to do HSM support on BCCSP [07:58] Vlad had done CFFSL has their own layer of singer on top [07:59] @vpaprots see above [07:59] you have to send future request, they are authenticated in authorization header that covers certificate.. and it contains sig, the sig contains the signature and the body. we need to do the signing wiht VSCSP.. [07:59] the signing in our CLI client [08:00] if we did on the server side- it does not mean that yo uhave to do at the same time as the SDK side [08:01] It comes down to request and re-enroll . On the CA side, the CA is some refactoring but perspective of using it, it works. so we need to finish the register from SDK- we have almost ready to check in,.. by default we use SHA384 (only register/reneroll for off token),.. we would have register and create new users, enroll already works beautifully (Jim integrated it).. we enroll and get cert back.. no more work on SDK side for that. [08:02] We just need to finish register and re-enroll.. do we take a cut. if you want to do a few things to clean up the document, it does not stop doing additional work. and we just take a cut of the CA before. so we can merge stuff after that.. and CA is in very good shape. [08:03] The only thing that is merged with HSM support for BCCSP.. BCCSP you can configure but it's not being used for HSM yet. Just like HSM is out of the peer. You know that the default you changed to 256- so this is hard coded.. I di dnot change I implemented to SHA 384.. it's hard coded today so we can't change it. [08:04] Intermediate CA support- I assume that is something that could wait, but i put that up there because the place where this is nice- if you set up a cluster of cop servers or fabric ca servers and you want to get enrollment certs distributed for them. you can start a root ca and cluster of intermediate servers that enroll with it.. I may be overly optimistic- this is 1 day's worth of work. it's not a big effort. Binh is saying this is very useful for testing out multiple MSP concept. it will be nice to have a single ca and generate something intermediate. IT's also nice to reknew a CA certificate ultimately. [08:05] if you do the first thing with Swagger doc.. and top list. if we are willing that SDk is not complete- you can use ecerts we have that working.. we have ability to node sdk to enroll, we finish register api, cop is up- you can get certificates fo rany # of peers for encorsement and for joining channels and connecting. We can use what Keith gets done. but we can take CA and build that out today and use that for the 31st. [08:05] If we don't have TCERT support throughout- that's fine [08:06] -------------- [08:06] For documentation [08:08] We should have remove the version 0.6,... we are already started on high level overview, high level architecture, glossary of terms, how to get docker up and running with compose,.. and how developers program against chaincode -- which includes APIs, channels, couchdb/ledger and chaincode. [08:08] Binh asking how much more we need to help on doc based on where we are- i need the apis and how to program against chaincode with Murali... Murali will sit with a couple of hours to step through all that stuff [08:09] need to have some prebuilt things- x number of the MSP- -we should at minimum in policy have that... for the docuementation things like query system chaincode, config system chaincode, [08:10] docker compose is self descriptive instead of reams of documentation-- just explain like was done before [08:10] @nickgaski @joshhus [08:11] Today we have sample config- we should have sifferent sample config and put them-- and use docker compose [08:11] and we generate the sample config [08:11] What does it mean to have identity to invoke chaincode? ours is a permissioned ledger.. this is important concept.. but we need to at least need to highlight that.. wecan go into details in MSP, but at minimum this should be outlined. [08:11] How can I use to invoke chaincode? [08:12] How about we have one config and config has identities that are pre-generated and we describe how we got identities and the places we are going to use [08:13] This is trying to explain the initial set for end of this month and starts to be the framework- i agree that a high level description of how membership is enforced- explain permissions are organization based, we will have notion of membership defined via crypto mechanisms and x509 based support and here is a simple paragraph on that [08:14] We then at end of this month- you want multiple orgs- each has x509 certificate- here is what you need to gather and we have worked out in api the config transaction for create channel has that MSP config struct. we make it simple at high level that the basics have MSP name plus the pem certificate and this is how it works. Then we can add more as we go along- it gives you the basic framework to start wtih [08:14] In addition with that- we do some configurations for reference- we provide with 3 organizaitons and here is 3 root certificate authorities and an MSP policy that is 2 out of 3 for endorsement and have at it. @bmos299 [08:15] Angelo indicated that we already have a lot of this written up- so Nick and Josh can pick up from the dock from Elli and team [08:15] ---------------------------- [08:16] What I want to do- put your name on the items on the board and you work on it-- I want to have a standup scrum at 3pm today where I will transcript again here on the fabric-dev channel. We will only do 2 things- what are the things preventing you from progressing? we will then keep people who need. [08:16] we will do this at 9:30 and 3pm and will post on the channel [08:17] if there is feedback from any of the items above from those not involved in discussion (where there were many)- please get with squad laters or Gari Singh or Binh Nguyen [08:19] With Clayton- we will take a quick break- we want to have discussion with Keith, Jim, and Binh so we talk about the scenario on how we use this- what is it that we expect to do on February 1st [08:19] This may further refine the list up above- again we should ask that the community contribute to what we have written here [08:19] ---------------------- weeds [08:26] @markparz highlighting that you need to read the channel [08:27] ----------------------- [08:28] We have drawn a pic on the board [08:29] Boxes are fabric-ca, orderer(solo), peer, SDK/App [08:29] We want someone to be able to program and use the fabric at end of month [08:31] Solo needs to come up- so someone needs to call create channel. There has to be a CA/Id that the orderer has to trust [08:32] From SDK you must be able to create channel (orderer) and join channel (peer) [08:33] Let's assume that we have multiple peers/cc 's [08:33] We have multiple peers/cc [08:33] Org1 peer, org 2peer, org 3peer [08:35] in orderer- you have config block (chain name, address of orderer, msp config- cert/anchor peer.. cert/anchor,. cert/anchor) [08:36] if we agree to this- the end scenario is that your application to prove out more than our single endorser.. [08:37] We have definition of create channel and taking in MSP config is in there.. but the orderer is not reading it; for create channel- the orderer takes what SDK channel takes so we have to come up with the right materials... jeff has it on the screen as he worked it. The only thing missing orderer is not taking generated MSP information- i already do it on the peer side. [08:38] Does the peer itself write to the block? yes.. does the peer load any of the information and loads into the channel MSP config and utilize for cert config [08:38] Current policy one of all members of the channel [08:38] Then why do we have to do any additional work for January 31st? [08:39] The local MSP for orderer.. do i care if orderer signs messages... the high level scenario write chaincode, deploy chaincode, and use basic policy that is more than one guy endorsing it.. 1 of MSP configured for channel [08:39] All the info is in messages ... [08:39] If you don't need access control- then we are done [08:40] simple scenario that works-- all the stuff surrounding it that we need to have some level of code, because in February we really need to start testing. [08:40] If I want to have someone use this thing- is it useable now and prove out basics of system. What is missing? should we just do doc improvement on this scenario? [08:41] WE can work on how we integrate the CA into scenario.. and process of SDK can utilize what Jeff did in his script already showing this scenario work. [08:41] If changes to from last week- too many merges can happen... and can hurt us [08:42] We should probably have ability to create multiple channels--- [08:42] (this works) [08:42] @bmoss299 we should make sure that this scenario up above is what is documented by Nick/Josh [08:43] Do we want to show negative checking? do we need to verify endorsements? it would be trivial to add a user that is not signed by cas that is not accepted by channel creation and that works- [08:43] for SDK to do the precheck- we need MSP on backend to be done and we do need work on SDK [08:44] Brett seems to be working on join channel... we need to publish those as mpms alpha version. you want to have a sample [08:44] on sample i would separate out deploy/invoke- here is how you create/join channel and here's how you deploy and invoke chaincode. [08:44] It can fail any one of those processes, but it helps to see those steps. we are in better shape than thought. We should take this same scenario [08:45] now we decide we add TLS or add authentication by ordering side and we should then iterate... we use the images from what we have [08:45] we could tag a version of master and build the images from there [08:45] ---------- [08:45] Current behave images- effectively the top part is the CA definition- you can see defined order nnetwork (only signle organization) [08:46] we have process a subject, a context, and a signer.. even though different verbiage we have admin tuple- cert from subject for context given an org [08:46] this guy orderer0signer, order0o, orderorg() this is cert that puts under orderer when it starts- we can pass the yaml file to orderer. you will have local MSPs [08:46] all that information is passed around [08:46] ordererOrg()- this points to org that points to pem file with self sgining [08:47] in scenario- we can decide if we do 3 cops- we can integrate that into scenario.. we can use ca for short [08:47] this minimizes and nick can improve on docs... Jeff feels he can generate docs dynamically [08:48] on volume- i'm going to output all the key artifacts [08:48] so organization- all key organizations you want to define, ie peer org2 [08:48] So now you have afccess to the organization- orderer generates the GUId- so ordersystemcainid... so we utilize this name [08:49] then bootstram creates chain policy- so basically i'm creating policy so thhree orgs can create channels , ie peer org0, 1/3 [08:49] so now signed items are created-- and now we have to create the msp using that policy (chaincreate policy 1) [08:49] Now you have to create the genesis block for that chain id using policy solo and referencing all tehse policies and associated names [08:50] chain creator does enforce that in that msp based on whatever that policy is [08:50] that creates the genesis block [08:51] We are missing a step instead of guy creating a block- the guy has to create the block data and collects signature on the orderer just like developer- orderer has to get the sigs if there is one org or multiple org in orderer. but we have to add that [08:51] But none of that is enforced today- no, but I don't want to miss it [08:51] so you tell that story- how we have to incrementally plug those features in [08:51] couple of other things- and this thing i'm defining th e peer network- this generates signer certs to each peer and peer starts with right local msp [08:52] i gave peer 0 to peerorg0 but peer 2 and 3 peer 2 in org 1, peer 3 in org 1 [08:52] this is template stuff-- [08:52] the next thing we do is identify developer for peer organization- give a subject and give context chaincreate policy1 (the one we gave to orderer) [08:52] this is like giving developer access to a space- because I don't want anyone using the peer certs .. this gives sdk it's own identity as example [08:53] peer org signs and devleoping in this space which we call chain create policy1 [08:53] I need identities for organization- so i chose peerorg0 and peerorg1 and this is subset of the genesis block- I could limit my channels to single org or subset of the org- [08:54] if you have create chain policy- you can add any org you want.. because it has to be in the orderers- right now it does.. how can they validate it. how can they verify the sig. they do verify sigs. you verify signatures of public but it has to be in trusted root [08:54] if i have create chain- theat everybody in this list-everyone has to sign it- so you have signature across the bytes, but remember these are the peerorgs you are asking for endorsement from cft ordering system- there has to be at simplest- you have to then decide continue certs .. so you have to have one guy must add a bunch of root cas of who can do a create channel . now I am allowed to create channels i should not have list and should go out and pick 15 other people as long as signed by those CAs ... [08:56] acceptance of block- i inspect,... or never join acceptance without signing. at what point will orderer enforce his certification. On broadcast [08:56] IN this scneario- we are defining the peer organizations before we bootstrap the orderer. the reason we are doing that is we don't support the reconfiguration. so now who are the endorsements and particpate in the channel i'm going to create [08:57] i create peer anchor set and I'm saying my anchor is from peer org 0, peer 2 from peer org 1 so I'm picking 1 out of each group [08:57] i crate signed envelope- i have to reference channel, template, chain creation policy name and the anchor [08:58] Thetemplate is a reference to the ones I'm going to use that i defined,.. chaincreate policy1 is a logical name must be used in all channel creation [08:59] So now i get my signed config envelope- the orderer should ask all the order to sign before genesis block- org 0 collects signatures ... [08:59] now create config transaction using signed above [08:59] i save as configtx1 and broadcast to orderer [08:59] I wait [09:00] then i connect to deliver fucnation and seek request with those properties with chainid [09:00] i should get delivery from order0 in 1 block within 1 second [09:00] i then request to join using genseis block on peer 0 with result [09:00] I am calling api on system chaincode [09:00] then let's say it works (which it deos [09:01] now i'm delivering waiting and what does happen- we got a 200 response from peer [09:02] for information on immediate up above Jeff Garrat can help [09:02] the only thing that is not there orderer is not using the cert available to it (peer does this already so similar code) [09:02] I just need to deploy and have code in deploy and ask for multiple endorsements at the same time [09:03] lot of steps to get network up and running [09:03] my docker network is running and you can use cli but developer should not run bdd- they should just run docker compose [09:03] it's more involved than that, because under the covers, i'm creating genesis file dynamically and also generating the local msp [09:03] so i create ca certs, pstore and parameterized [09:04] docker compose can bring up entities unles syou hard code- so now you need scripts to link them together [09:04] We have to do the work on SDK sde to make this work and they should replicate this [09:04] ARe you saying angelo we support one of msp policy today- we do on VSCC [09:05] do you define that at the ESCC side? they do have to match but we have the one of [09:05] and does that work when you deploy chaincode- we have to work that- which is chaincode lifecycle [09:05] which is in the list [09:05] we have everything to joined channel and we can inject deployment [09:05] but deployment not ready yet to deploy chaincode- you need one of policy--- we need that [09:06] if we expect people to not break apis' we probably need chaincode return object [09:06] it is implemented but merged and committed and documented [09:06] you need deploy transaction and need in SDK to specify the ESCC policy [09:07] Jeff- if i look at the log for gossip peer- which is peer 1- i see something that is concerning- [09:07] there is "no such channel" on the anchor i would tag master and build and go through 20 steps and everything provisioned [09:10] there is a mismatch in gossip and way we are encoding [09:10] VSCC would only check to see if one of members is singing [09:12] Things for absolute minimum- chaincode return object, chaincode endorsement policy, escc/VSCC, events support (includ rejection ), chainjoin (creation basically needs to get done) [09:15] The rest of the other items should progress- but we know what the most important it is [09:16] The other piece we MUST decide on is chaincode lifecycle ry [09:21] @weeds @ghaskins that will be on the wiki soon [09:25] @weeds what is the context for this? [09:54] https://wiki.hyperledger.org/community/fabric-notes weeds [10:33] @ry Binh met with several people that develop on the fabric [10:34] We already have docker images that people can utilize (not sure it's all checked in), but we wnat to make sure for the hackfest that we have all the right pieces for people to [10:34] 1) start up the fabric [10:34] 2) be able to bootstrap a network [10:35] 3) be able to join, create and deploy chaincode on multiple chains based on who is allowed to be in that channel (ie we have multichannels working) [10:36] 4) they should be able to do the full transaction from sending transactions to the endorsers (where a policy is set- for example one out four endorsers can approve the transaction), be able to send to orderer and have it ordered and then put into the ledger (whether couchdb or level db).. they should be able to query the result---> this should be able to be done against multiple channels [10:36] 5) who is allowed on the channel is important part of scenario [10:37] As a result the items above- we took assessment where all the pieces are in the fabric (there are some holes as not everyone anted up information during hte call)... and highlighted what we thought we needed to be done. So you will see categories of fabric, SDK, BDD (for testing) , documentation, and cop [10:37] after that, and this is probably where the notes got fuzzy, Jeff Garrat took us through BDD showing how to bootstrap the network [10:38] as this is already working and flowing an what minor pieces just need to be completed there
Notes from Fabric Discussion 23-JAN-2017 afternoon
notes from Sharon Cocco (weeds):
weeds [13:20] another quick conversation--> Now the thing that we can do, we can run Jeff Garrat's BDD- capture the block, put in sample directory and we run with that. That allows our CLI to work,.. that would allow the demo scenario to work with the new configuration block. With that configuration block- what would we have to do to submit that transaction to the orderer. Have you look at config txt template stuff? Basically there is under config tx test thereis order template file and peer template file. This is the statically exported thing (not fromjeff's tool) this is configuration tool.. and feed in new chain- and spits out the transaction you have to spit it out to create a new chain- there is no import cycles,etc,.. [13:21] So what if you did this? bring up compose, another docker container we boot up and tells people to console into it (exec batch into it).. it has the CLi and it has a series of commands... it can be any of those things. You can log into xyz, you run CDE,.. and then your thing is initialized an dyou can run your nodejs.sdk to run your transactions. People just have a hard time running CLI-- it allows us to use docker and not vagrant. Have a CLI container and do stuff. We just add additional commands- this is admin configuring the network. So you want to create chain and here's what you do. [13:21] We can do that easily without channel create. and specify flag default cahnnel, use your template. [13:22] You can actually do interactive- whatever command you run- you run batch script and then test just exec docker and run as a command line and without invoking the container- htat is how we did this last week, we put it in a container [13:22] As long as we don't hardcode, but include the "generation part"... how many templates... let's just cli create to take argument where CLI chain create command will it do it for you.. we will call the templates [13:23] so now on board -- we are adding CLI channel create for alpha [13:24] Jeff has this working in behave- it's completely parameterized.. you get a language- you can add orgs, change orgs, create as many channels you want, create as many order networks.... will we intimidate developers to do that... Jeff says- it would be good to do a python setup .. you can clone the get... Actually, what we should really do is bake into the image.. Behave stuff drives docker compose.. and you can drive docker.. bind in the docker socket. ghaskins [13:24] @vpaprots @harrijk @ramesh regarding: https://gerrit.hyperledger.org/r/#/c/4359/ [13:24] how do we want to proceed ? vpaprots [13:25] talking with John atm.. ghaskins [13:25] ok [13:25] ill look to you guys: if you come back and are confident my concerns are unfounded, ill remove my -2 vpaprots [13:25] John showed me that softhsm was not installed.. and I forgot that its debian.. harrijk [13:26] I think for the first step, we'll need to get softhsm2 into testenv for fabric ghaskins [13:26] ok, thats a very low-risk proposition from my perspective vpaprots [13:26] I do need it in asap, sitting on quite the few changes that cant go in without it.. but.. found some issues with how I specify pkcs11-slot. weeds [13:26] what is important is they need to have an admin thing that is clear-- so the only way to build an app is to use the SDK.. we should have two simple scripts that create channel to call the apis-- just to make it easy. ghaskins [13:27] (sorry weeds, cross-talked over your stream of consciousness ;) weeds [13:28] We are set on CLI and run clis in an interactive docker container. So we are going to modify channel create.. it will take default template and use it as the configuration (it's ok greg- just trying to capture discussion here for your guys- can't tell if you can even follow the stream of consciousness) ghaskins [13:28] understood, just apologizing for interrupting it weeds [13:29] Jason- how would in default template get cert--- you would have to regenerate the template. Basically the tool that I keep alluding to essentially is order admin tool that connects to and dumps a template chain by looking at the block [13:30] The tool does not exist- there is a static tool that exists, but we need this to work at run time. then we would check template in and can be generated... as part of the compose once you are running services which dumps template and would be fed into chain creation tool [13:31] My developer needs a private key- we self generate all that stuff. we will have docker image for the cli.. so we could just use a shared volume to the local msp which is needed for that key and bake it in ahead of time... hmmm. the one jeff does bdd does it through shared volumes. someone is outside of docker writing a node app.. he has to find stuff.. if we just started a container rather than docker run, we can do docker exec,.. you could template, keys being there,etc,.. [13:33] in their application, where do we get their certificate from- there in a shared volume- they are on local file system,,.. you could put that in... that would be the easiest thing to do.. REally Jason said he needs to talk about the SDK guys - they really should not know how to do that and pick up from template and be able to print them,. .for now it's an efficiency, because we only have templates working is in go.. but that really should be in sdk at this point [13:33] Binh suggested maybe give them an api to implement? Jason said- ok.. give them an api to use the templates we generate. Open a JIRA or slack it to them? Slack it to them. [13:34] Barry- maybe I have Latitia to help you? Jason- I would love to get more people to know how this works. It's tying hte config and node program and spinning up something quickly. [13:34] (we need to forget not to miss the java sdk) [13:35] There are some questions for Jim in terms of validation process for Barry and Latitia [13:35] We have an image, spins up fabric, runs templates,.. which crypto mounted to volume and then tell sdk here is how you connect and use this. [13:37] Just to get someone writing ... the thing with say I had another image he spins everything up and it's a done deal for me- i have all certs and network. if I run a behave (instead of the cli) run the docker image that runs the behave- we mount that.. in behave, you would have to generate all the cert stuff.. it will do it for you.. we just tell the end user.. hey sdk developer- yo uare ready to go. If you just basically toe do not decompose.. if you can get an image.. put. now we can hardcode behave .. maybe that's an easier fix. [13:38] Which is better? at end of the day, people are going to have to know how to create the configuration transaction and you won't have all your stuff in one place and you will have to deal with templates... Yes, that's true. [13:38] The big thing is can you make behave from inside a docker container-- that's going to be the question- you can bind docker socket into docker image. That's unit test, but Jeff might know. ghaskins [13:48] @weeds: on that front, it was my intention, though I have yet to prove it out that "make behave" would eventually drive the behave tests with a "$(DRUN) behave", similar to how we do unit tests [13:49] as part of that, I would be moving the python installation stuff that we currently do in the baseimage to be within the testenv container that is JITted as part of the build [13:50] from there, it should be straight forward to grant the behave container permissions to dockerd for its own control of futher containers, similar to what we do in other places [13:50] but where I am going with this is: I woulnt classify it as "make behave" running in a container, as much as "make behave" drives behave within docker [13:50] thats probably the same thing you meant, but good to clarify binhn [18:15] @ghaskins :+1: We were talking about what would be the best way to help app developers set up a working environment, and the thought was to run a bdd feature (pick an appropriate one) ghaskins [18:16] ah, as in use bdd to help create an app developer environment? binhn [18:17] yes, but we wouldn’t want developers to have to install vagrant + other tools, just bring up a docker image to run the bdd from it ghaskins [18:17] ok, but we are already largely there, arent we ? [18:18] the majority of functions (excluding bdd) only need make/git/docker/docker-compose [18:18] and I think bdd could be brought into that fold fairly easily [18:19] some of what you are talking about reminds me of this old issue: https://github.com/hyperledger/fabric-chaintool/issues/5 GitHub add "chaintool new" · Issue #5 · hyperledger/fabric-chaintool · GitHub Would be nice if the tooling could emit a skeleton project to get things started, similar to "lein new". binhn [18:19] i think the work is to enable bdd inside a container to create images and launch other containers ghaskins [18:20] I was envisioning a user doing something like "chaintool new" and it will spit out a skeleton chaincode app [18:21] it would be fairly easy to make different profiles that are both CCI based and those that are not [18:21] not sure if that is exactly what you were looking for though binhn [18:22] and “chaintool new” with an option to launch an env and deploy the app ghaskins [18:22] ok, i see where you are going [18:23] yeah, you could use chaintool code-generation capabilities to spit out whatever you wanted, and then drive an environment with docker-compose [18:23] it would mostly be a function of defining the templates that we need [18:24] chaintool is currently based on the stringtemplate engine (http://www.stringtemplate.org/) binhn [18:24] right and that is done with bdd features today, so we were thinking about capture that in an image, but it can definitely chaintool ghaskins [18:25] ok...i think regardless, moving towards integrating bdd with the $(DRUN) stuff makes sense binhn [18:27] agreed [18:29] @ghaskins btw, we could use some feedback on this chaincode deployment proposal https://jira.hyperledger.org/browse/FAB-1783 ghaskins [18:29] will take a look, thx binhn [18:30] thanks
Notes from Fabric Discussion 25-JAN-2017 morning
notes from Sharon Cocco (weeds):
weeds [06:35] Ok Binh came by open area and a few people congregated---> Here are some notes as a result jyellick [06:35] Note that we also need to fix the hashing of the data block, which is targeted to be done as a Merkle tree, but again, unless someone is interested in maintaining the hash chain, I'm not sure what the value of computing this hash is. weeds [06:36] Chaincode Ednorsement policy did make it in- there is still another 1/2 to go [06:36] For Chaincode REturn object - this one is in,.. and everyone needs to rebase- this is going to change your chain code... This guy is to return different status code on every chaincode [06:37] Anchor peers is blocked because the peer needs the handler finished which Jason Yellick has pushed some of this-- If Jason's stuff is checked in, we can proceed [06:38] All peers connect to the ordering service- you need to join the channel at bootstrap- that code has to be written, because not all peers will get the identity channel--> Jason Yellick owns this jyellick [06:39] @weeds I can hopefully get this done today. [06:39] (Am on the hangout, but cannot hear anything) weeds [06:39] We are almost done with the system chaincode refactoring which will come in this AM- Murali did that work [06:39] Chaincode calling chaincode is almost 1/2 way there- Binh is debugging [06:39] CLI channel to create default- barry is working on that relative to the docker image [06:40] For ledger with Dave enyeart- there are change sets out for finishing couch miscelanous items and query.. we ahve questions on refactoring for chaincode API- he is going to get with Murali [06:40] Change set on history of key values 9LEVEL DB) IS ALMOST READY (SORRY CAPS) [06:41] the phantom read work done by Manish is readyy and checked in for review and has +1 reviews from David- needs Binh or Gari to review this. [06:41] One of the issues is that everyone is so busy- noone is doing the reviews- we need help on this [06:41] In terms of getting couch environment into docker for next week- Dave Enyeart talked to Barry - bmos299.. we left it that after you get simple happy path, we will add couch to docker compose. rickr [06:42] @jyellick I think we will eventually need to parse it to get the block number when monitoring what transactions have processed. The blocknumber will make sure we don't process this again 1 reply Today at 06:43 View thread weeds [06:42] For docker- we have basic path working, we are adding sdk.. Adnan is adding the couch stuff to it [06:42] Barry is working with Adnan jyellick [06:43] replied to a thread rickr 06:42 @jyellick I think we will eventually need to parse it to get the block number when monitoring what transactions have processed. The blocknumber will make sure we don't process this again https://hyperledgerproject.slack.com/archives/fabric-dev/p1485355326001776 1 reply jyellick 06:43 rickr: You can certainly get the block number, but I'm not sure why you need to compute the header hash? https://hyperledgerproject.slack.com/archives/fabric-dev/p1485355392001779?thread_ts=1485355326001776&cid=C0YPYBVJM weeds [06:43] On the finalized QSCC block tran structures- we talked about that yesterday. I sent a draft of whta we talked about and we will post in community on the channel- one of the questions was get transaction by id- we trun the tran protostructure, but header is above that, but header is importnat.. that is transaction id, time stamp.. so we may need to return the payload. it should be clear in the proposal for that... Dave Enyeart to post this to get feedback from community [06:45] to ARtem- when we do state synch, are we calling same api to get block from one peer to send to another peer? they are using committer,.. but I think it does use same api.. we need to see if it's a lower level of apis that manipulates bytes... the lower level gets block by # and retunrs the unmarshalled block proto... that's what synch wants to do. maybe we have to optimize and suck the entire file over... Right now, it calls get block... that's very inefficient. We do a lot of marshalling and unmarshalling.. repeated. Dave is saying we need synch that works on serialized block then. Artem says ok. This is not for immecdiate, but needs to be logged in JIRA so as not to forget for optimization and performance (which is focus in February) [06:47] On the SDK- there is outstanding chainset that needs to be approved. we're still making progress on event support and join chain. both are going in parallel. we are working on initializing the MSP that is needed to send create chain request to orderer. All is still on going. We are targetting event support completion if we don't get all chain creation and chain join-- is that ok? we will have to use CLI... that is the backup plan .. there is a lot of moving parts for chain creation, but we do want to get events support done. WE haven't added the references to ESCC or VSCC to deploy yet-- that is higher priority it seems like.. this is so application can execute. [06:47] For event support- i merged chainset that Pat implemented new messages [06:50] What is ESCC /VSCC is needed? this is absolutely needed for endorsement. Has something changed? There are defaults being used.. there is an item that Murali has worked called chaincode lifecyle and endorsement policy. Currently transaciton comes in, we just say ok fine... but once we have endorsement policy which is mostly done- transaction must be signed by John. The work on the SDK side is adding a new field to the proposal , identifying ESCC and VSCC by name, which is really not significant,.. and we can add that support.. Policy being things like 3 out of 10 sigs... We can defiintely identify and add in there for policy or we can also default system for this round. Supposedly application should do preliminary checking on responses- if it's not meeting the policy- it should discard. Right now, we are just sending things over where VSCC will catch that. I'd like to keep that as is for end of month for alpha. Yes, sounds reasonable... we do think key to send in ESCC, VSCC, and policy. The CR that I talked about with endorsement policy is out there. it's called post it notation.. end/a/b something like that. you need signature for a and b... is that a string? [06:50] from application, we haven't decided from community whether string goes all the way to the peer or deployment... or the SDK would proto this into structure- i suspect it's going to be at the peer for desing sake. [06:50] CLI we can do this already [06:51] Documentation- There is higher level pieces,.. maybe 7 or 8 separate higher level topics as an overview documentation for the community. 2 that are basically done and we can complete remainder in day or 2... and knock out the rest of the stuff with the various people assigned. [06:54] we need a sample, Question is what do we show for policy, MSP,etc,. and need some input from the community for this first round ... We do need to probably talk about system chaincode and the apis.. that has to probably come from Murali or Binh at this point. Performing a query against couchdb we do need to include for complex queries should come from Dave Eneyart [06:56] When they do the docker compose for getting started- it will have example 2 chaincode. [06:57] in text, you can create a channel, join a channel with these # of peers, there is a CA set up, here is your node sdk.. do an enroll and signing cert ,.. we provide a very basic nodejs program.. so at least people have some artifacts to give feedback on. text, you can create a channel, join a channel with these # of peers, there is a CA set up, here is your node sdk.. do an enroll and signing cert ,.. we provide a very basic nodejs program.. so at least people have some artifacts to give feedback on. [06:58] we have docker images published somewhere, the docker compose that ties all together, and zip file with some generated materials in generated location so people can connect to it- this gives you network that works,.. another file that shows application code, mpm install and run... seems like maybe that will help get people get started next week? [07:00] One thing in the YAML we should remove- the fields in security section need e removed -- all those really are not appropriate- that security seciton is getting removed- [07:00] Chaincode interface chain really is a big bug-- that has to get updated [07:00] someone could help that and rebase adc [07:06] okay, @jyellick @jzhang @rickr, what I want to say is that ASN.1 is preferable solution, I would say. We can avoid it if necessary. If we do, let's have it properly documented jyellick [07:16] @rickr @jzhang I'm still trying to understand why the SDK ever needs to compute this hash weeds [07:26] Binh had discussion with Elli and Angelo- I have a function called check acl,. This is the chaincode calling chaincode- before we set everything to invoke another chaincode specification, we check the acl.. and what that means is what we want to do is to check to see whether this transaction in proposal the signature is valid on this channel.. so imagine that chaincode 1 calling chaincode 2. chaincode 1 on channel 1, chaincode 2 on channel 2, chaincode 1 is invoked by user 1... so when proposal comes in, we verify the signature against that user 1 against the config block on channel 1... so now when chaincode 1 calls chaincode 2 on channel 2 passing along the proposal.. so now we have to verify again the user 1 signature against the channel 2 where chaincode 2 is on.. so this is what happens in check acl. but we seem in code to be missing a few pieces- [07:28] there is check sig from creator- message validation go... it's a local function.. I think I can call this function, but this function- is that it's local, so we need to change to global. but the problem is this- it takes the information we only have from a side proposal, which is at this point is in the handler at this point.. the only thing we have is th eproposal, we don't have side proposal. I want to talk to someone who created this- Elli, angelo, ale? do we need all of this- can we work with proposal or side proposal to call this function? We can get message bytes is the side proposal is the proposal bytes itself... [07:28] We either have to change our handler to pass the enitre proposal.. versus just the proposal given by this function. [07:29] Is this happening on the same peer? you can assume that the proposal has already been verified, because it's verified in the first channel, so you don't have to verify anymore- if the peer is malicious- it's malicious. [07:29] We have to assume the peer is doing the right thing- let's assume that this user has access to channel 1 to do something but this user does not have access to channel 2.. even though the peer joins both channels. So in this case you do need this. [07:30] We do need to enforce the ACL on both channels- [07:31] that function calls from validate proposal and check sig- creator is respect to this one chain.. is there a chain id on that? yes... we are assumin the creator verified on channel 1.. that same creator instance can be used... so yes.. if you have creator bytes you re fine.. so how do you check the read set and write set- how do you know? the read can be modified on a different channel. we don't do any of that except we verify tat the user signature is verifiable on channel 2.. we need to develop that (Angelo working on that)... ARe you saying you get read/write set of chain? what does read/write set on 2nd chain? how do we resolve version conflicts regardless of access control? [07:32] If you read the JIRA item- it's a read only and and there is no read/write set for the called chaincode. [07:33] if the query is on the same chain as chaincode- you have read/write set of the chainocde and verify vscc shcek . but on different channel, we can ONLY do read and query only [07:33] there is no read set- we are not sending read set from chain 2 inside.. the only thing proposal response has is the read/write set is for the first call of the chain. [07:34] WE do have the read/write set collected on the same channel and it's working-verified [07:34] but on different channel we do not want to collect the read/write set on the 2nd channel- we only want to return the value. [07:35] Now that you mention it- there is one more thing you need to do when doing different chains-- but same logic calling- it's going to try to include it and we need to fix that on the 2nd chain [07:35] From security point of view- we can check the signature- yes? [07:36] the 2nd chain code is working like an oracle.. it might be an endorser that might get a different value.. so you might see a transaction be rejected.. yes, sdk would reject. this has to be calirifed to the developer.. it depends on how you implement- if you go to oracle- give me the current value- because endorsers might end up with different view, but security of execution-- you do same process when proposal first came-- is the oracle value has to be included what the endorsers endorse- the read set... but not clear if this makes sense- it's up to the calling chaincode if they want to... because eventually the value is considered by calling another chainocde will effect the outcome of the execution of that chaincode [07:37] if the value was idfferent, then the outcome is different,.. and the end result of that proposal would be different [07:37] there is no difference if you even have a regular call outside the blockchain [07:38] how do you replay the blockchain in this case? [07:39] this would allow for non-determinism [07:39] if 3 endorsers get the same response- it will have same simulation, endorsement will succeed and commitment will be validated despite the chaincode is not replayable [07:44] you have endorsement- you send read/write set... you signed agreeing to set of inputs and you got outputs. [07:44] proposal come in and you want to include external data- you need to put it into key... you have to do that. [07:44] This is the same as keys we read without modifying [07:44] the big point is this there are rules for writing chaincode [07:44] 1) access only state variables on database [07:45] 2) if you access something external and you are on your own and you better record it somehow [07:45] This is true whether calling chaincode or calling external source [07:45] @bmos299 please make sure in doc this is recorded clearly point 1 and 2 up above sandra.vrtikapa [07:48] joined #fabric-dev sandra.vrtikapa [07:50] Currently I can only receive/access chaincode events via block events. If I set a chaincode event in user chaincode and that part of the code doesn't generate block event later on I am not able to receive my chaincode event. Is there a plan to support sending/firing chaincode events from user chaincode independent of block events? ghaskins [08:28] @pmullaney ^^^ pmullaney [08:39] @sandra.vrtikapa : if you set a chaincode event in a chaincode, you will generate a block( or be included in a block) new messages [08:40] if you use the upcoming eventhub in the v1.0 api, you can just register for a chaincode event - eventhub takes care of parsing the chaincode event from the block it receives [08:41] I hope that clears the question up if not ask awaytext, you can create a channel, join a channel with these # of peers, there is a CA set up, here is your node sdk.. do an enroll and signing cert ,.. we provide a very basic nodejs program.. so at least people have some artifacts to give feedback on. [06:58] we have docker images published somewhere, the docker compose that ties all together, and zip file with some generated materials in generated location so people can connect to it- this gives you network that works,.. another file that shows application code, mpm install and run... seems like maybe that will help get people get started next week? [07:00] One thing in the YAML we should remove- the fields in security section need e removed -- all those really are not appropriate- that security seciton is getting removed- [07:00] Chaincode interface chain really is a big bug-- that has to get updated [07:00] someone could help that and rebase adc [07:06] okay, @jyellick @jzhang @rickr, what I want to say is that ASN.1 is preferable solution, I would say. We can avoid it if necessary. If we do, let's have it properly documented jyellick [07:16] @rickr @jzhang I'm still trying to understand why the SDK ever needs to compute this hash weeds [07:26] Binh had discussion with Elli and Angelo- I have a function called check acl,. This is the chaincode calling chaincode- before we set everything to invoke another chaincode specification, we check the acl.. and what that means is what we want to do is to check to see whether this transaction in proposal the signature is valid on this channel.. so imagine that chaincode 1 calling chaincode 2. chaincode 1 on channel 1, chaincode 2 on channel 2, chaincode 1 is invoked by user 1... so when proposal comes in, we verify the signature against that user 1 against the config block on channel 1... so now when chaincode 1 calls chaincode 2 on channel 2 passing along the proposal.. so now we have to verify again the user 1 signature against the channel 2 where chaincode 2 is on.. so this is what happens in check acl. but we seem in code to be missing a few pieces- [07:28] there is check sig from creator- message validation go... it's a local function.. I think I can call this function, but this function- is that it's local, so we need to change to global. but the problem is this- it takes the information we only have from a side proposal, which is at this point is in the handler at this point.. the only thing we have is th eproposal, we don't have side proposal. I want to talk to someone who created this- Elli, angelo, ale? do we need all of this- can we work with proposal or side proposal to call this function? We can get message bytes is the side proposal is the proposal bytes itself... [07:28] We either have to change our handler to pass the enitre proposal.. versus just the proposal given by this function. [07:29] Is this happening on the same peer? you can assume that the proposal has already been verified, because it's verified in the first channel, so you don't have to verify anymore- if the peer is malicious- it's malicious. [07:29] We have to assume the peer is doing the right thing- let's assume that this user has access to channel 1 to do something but this user does not have access to channel 2.. even though the peer joins both channels. So in this case you do need this. [07:30] We do need to enforce the ACL on both channels- [07:31] that function calls from validate proposal and check sig- creator is respect to this one chain.. is there a chain id on that? yes... we are assumin the creator verified on channel 1.. that same creator instance can be used... so yes.. if you have creator bytes you re fine.. so how do you check the read set and write set- how do you know? the read can be modified on a different channel. we don't do any of that except we verify tat the user signature is verifiable on channel 2.. we need to develop that (Angelo working on that)... ARe you saying you get read/write set of chain? what does read/write set on 2nd chain? how do we resolve version conflicts regardless of access control? [07:32] If you read the JIRA item- it's a read only and and there is no read/write set for the called chaincode. [07:33] if the query is on the same chain as chaincode- you have read/write set of the chainocde and verify vscc shcek . but on different channel, we can ONLY do read and query only [07:33] there is no read set- we are not sending read set from chain 2 inside.. the only thing proposal response has is the read/write set is for the first call of the chain. [07:34] WE do have the read/write set collected on the same channel and it's working-verified [07:34] but on different channel we do not want to collect the read/write set on the 2nd channel- we only want to return the value. [07:35] Now that you mention it- there is one more thing you need to do when doing different chains-- but same logic calling- it's going to try to include it and we need to fix that on the 2nd chain [07:35] From security point of view- we can check the signature- yes? [07:36] the 2nd chain code is working like an oracle.. it might be an endorser that might get a different value.. so you might see a transaction be rejected.. yes, sdk would reject. this has to be calirifed to the developer.. it depends on how you implement- if you go to oracle- give me the current value- because endorsers might end up with different view, but security of execution-- you do same process when proposal first came-- is the oracle value has to be included what the endorsers endorse- the read set... but not clear if this makes sense- it's up to the calling chaincode if they want to... because eventually the value is considered by calling another chainocde will effect the outcome of the execution of that chaincode [07:37] if the value was idfferent, then the outcome is different,.. and the end result of that proposal would be different [07:37] there is no difference if you even have a regular call outside the blockchain [07:38] how do you replay the blockchain in this case? [07:39] this would allow for non-determinism [07:39] if 3 endorsers get the same response- it will have same simulation, endorsement will succeed and commitment will be validated despite the chaincode is not replayable [07:44] you have endorsement- you send read/write set... you signed agreeing to set of inputs and you got outputs. [07:44] proposal come in and you want to include external data- you need to put it into key... you have to do that. [07:44] This is the same as keys we read without modifying [07:44] the big point is this there are rules for writing chaincode [07:44] 1) access only state variables on database [07:45] 2) if you access something external and you are on your own and you better record it somehow [07:45] This is true whether calling chaincode or calling external source [07:45] @bmos299 please make sure in doc this is recorded clearly point 1 and 2 up above