guoger (Thu, 02 Nov 2017 01:54:56 GMT):
Has joined the channel.

chokha (Sun, 05 Nov 2017 19:41:12 GMT):
Has joined the channel.

rjones (Thu, 16 Nov 2017 14:09:44 GMT):
cbf

cbf (Thu, 16 Nov 2017 14:12:19 GMT):
User User_1 added by cbf.

cbf (Thu, 16 Nov 2017 14:12:19 GMT):
User User_2 added by cbf.

cbf (Thu, 16 Nov 2017 14:12:19 GMT):
User User_3 added by cbf.

HandsomeRoger (Mon, 20 Nov 2017 08:00:13 GMT):
Has joined the channel.

harsha (Tue, 21 Nov 2017 15:01:45 GMT):
Has joined the channel.

jackeyliliang (Fri, 24 Nov 2017 02:59:00 GMT):
Has joined the channel.

heath (Tue, 28 Nov 2017 06:13:08 GMT):
Has joined the channel.

rjones (Thu, 30 Nov 2017 21:08:01 GMT):
https://gerrit.hyperledger.org/r/#/c/15847/ needs one more +2 to merge please

tkuhrt (Wed, 06 Dec 2017 11:08:01 GMT):
Has joined the channel.

muralisr (Sat, 09 Dec 2017 17:01:46 GMT):
@guoger @swetha can you suggest some good doc links for EVM exploration please ?

guoger (Sat, 09 Dec 2017 17:02:35 GMT):
https://github.com/ethereum/wiki/wiki/White-Paper#code-execution white paper explaining Ethereum, which contains a section about EVM

guoger (Sat, 09 Dec 2017 17:03:11 GMT):
https://www.gitbook.com/book/ethereum/frontier-guide/details a lengthy, but detailed guide to Ethereum Frontier release

guoger (Sat, 09 Dec 2017 17:03:58 GMT):
http://yellowpaper.io Ethereum yellow paper, supposed to be definitive and generic, where a spec of EVM can be found

guoger (Sat, 09 Dec 2017 17:04:26 GMT):
(If somebody simply want to learn about Ethereum, white paper is really good material

guolidong (Tue, 12 Dec 2017 06:02:17 GMT):
Has joined the channel.

cbf (Wed, 13 Dec 2017 21:40:11 GMT):
@guoger @swetha how are things progressing?

swetha (Wed, 13 Dec 2017 22:10:17 GMT):
@cbf: We have all the pieces we need to run the evm as a chaincode on fabric. We have started looking into the web3 json rpc API needed so that ethereum dApps can communicate with the smart contract and platform. Once we some of the API implemented we should have a POC that we can share/demo. @guoger anything I missed?

guoger (Thu, 14 Dec 2017 15:46:27 GMT):
@swetha after some experiments, I felt it's indeed easier to implement evm as a system chaincode, main reason being that we don't really have a mechanism to dispatch txs to a *singleton user* chaincode based on type, i.e. if the chaincode invoked is _EVM_, send it to _the_ EVM container, otherwise send it to container with corresponding chaincode.

guoger (Thu, 14 Dec 2017 15:46:27 GMT):
@swetha after some experiments, I felt it's indeed easier to implement evm as a system chaincode, main reason being that we don't really have a mechanism to dispatch txs to a *singleton user chaincode* based on type, i.e. if the chaincode invoked is _EVM_, send it to _the_ EVM container, otherwise send it to container with corresponding chaincode.

guoger (Thu, 14 Dec 2017 15:47:54 GMT):
I'm putting pieces together now and should be able to have a working poc early next week

guoger (Thu, 14 Dec 2017 16:07:58 GMT):
To adapt to web3js, maybe we could quickly prototype a JSON RPC server using node-sdk/go-sdk?

guoger (Thu, 14 Dec 2017 16:22:03 GMT):
@muralisr if I understand correctly 1. during _install_, code bytes are put in fs on peer 2. during _instantiate_, we first invoke `lscc` to put ChaincodeData into ledger, then invoke `init` on new user chaincode, where a new container will be launched if not existed. correct?

swetha (Thu, 14 Dec 2017 16:43:00 GMT):
@guoger: I am working on creating a JSON RPC server that implements a few of the instructions like sendTransaction and thinking to just have that use the go-sdk to talk to fabric. I will try to have something for the POC early next week.

guoger (Thu, 14 Dec 2017 16:44:13 GMT):
Great!

cbf (Thu, 14 Dec 2017 18:01:42 GMT):
fantastic👏🤣

cbf (Thu, 14 Dec 2017 18:01:42 GMT):
fantastic👏

silasdavis (Fri, 15 Dec 2017 14:08:01 GMT):
@swetha it would be good to collaborate on a go-based web3 RPC, this is something I need to build for Burrow

silasdavis (Fri, 15 Dec 2017 14:08:12 GMT):
so let's make it some kind of reusable facade

muralisr (Fri, 15 Dec 2017 15:32:00 GMT):
@guoger to answer your question ^^^, correct.

muralisr (Fri, 15 Dec 2017 15:36:32 GMT):
@guoger `I felt it's indeed easier to implement evm as a system chaincode,` - sounds right to me too.... other nice property, going by your "singleton" comment, is that you can choose between peer wide system chaincode (ie, across all channels) or a syscc per channel

muralisr (Fri, 15 Dec 2017 15:37:09 GMT):
I'm not sure why you'd need the peer wide syscc but its there if you want it

swetha (Fri, 15 Dec 2017 16:56:54 GMT):
@silasdavis: We like that idea too! For the time being we want an end to end POC so we are making an minimal server than we can use to test with. We aren't going to implement more than a couple of the APIs.

silasdavis (Fri, 15 Dec 2017 17:04:35 GMT):
That makes sense, I'll be sure to steal what you do if you get there first, then you'll be able to pull any changes I make based of your stuff

silasdavis (Fri, 15 Dec 2017 17:04:52 GMT):
Is this code pushed somewhere?

swetha (Fri, 15 Dec 2017 17:09:06 GMT):
No, not currently. What I have right now is a simple server that does not do anything. I am new to JSON RPC so mostly playing around with it. I will push it all up soon, latest sometime next week and be sure to send you the link

compleatang (Sun, 17 Dec 2017 22:26:23 GMT):
Has joined the channel.

guoger (Mon, 18 Dec 2017 15:19:55 GMT):
@swetha just an update, I pulled in your code, and get most pieces working: - compiled solidity bytecode can be installed via CLI - CLI can invoke functions in the same way as other chaincodes, but with the hashed args as defined in Solidity - an `evmscc` executes the code One remaining problem (hopefully last problem) is that when EVM actually `PutState` or `GetState`, I got error saying tx context is lost. Not sure why, will investigate tomorrow

guoger (Mon, 18 Dec 2017 15:23:40 GMT):
btw, let's use [this](http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html) example for our demo, and compile it with online compiler [Remix](ethereum.github.io/browser-solidity)! I've been fighting this stupid compiler problem for couple of hours today and realized my local `solc` compiler produces different bytecode than Remix

guoger (Mon, 18 Dec 2017 15:23:40 GMT):
btw, let's use [this](http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html) example for our demo, and compile it with online compiler [Remix](ethereum.github.io/browser-solidity) ! I've been fighting this stupid compiler problem for couple of hours today and realized my local `solc` compiler produces different bytecode than Remix

swetha (Mon, 18 Dec 2017 17:23:33 GMT):
oh that's really interesting, thanks for the tip

muralisr (Mon, 18 Dec 2017 20:55:32 GMT):
@guoger `One remaining problem (hopefully last problem) is that when EVM actually `PutState` or `GetState`, I got error saying tx context is lost. ` - are the Get/Put part of the invoke call to the chaincode (as oppoised to EVM initiating Put / Get outside of the the Invoke) ?

muralisr (Mon, 18 Dec 2017 20:55:41 GMT):
hope not

muralisr (Mon, 18 Dec 2017 20:56:19 GMT):
other possibility is the invoke request on the peer side got tired of waiting for response and timed out

guoger (Tue, 19 Dec 2017 01:43:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=7YiNQcaDQ4xMyAvpw) @muralisr They are part of invoke. Is new txctx created every time a chaincode is invoked? what `evmscc` does today is: - call `lscc` to retrieve evm bytecode based on chaincode name - execute that bytecode in vm - if bytecode calls `SetStorage`, it's translated to `PutState`

guoger (Tue, 19 Dec 2017 01:44:44 GMT):
What I observed is that txctx (key being `channel name` + `txid`) is deleted after the initial `lscc` call

swetha (Tue, 19 Dec 2017 03:53:38 GMT):
@here We are thinking of doing a demoing our POC, please ping either @guoger or me if you are interesting in joining the call. We are thinking of Wednesday (US folks: 8am PST, 11 am EST, London: 4 pm, China: 12AM)

swetha (Tue, 19 Dec 2017 03:53:38 GMT):
@here We are thinking of doing a demoing our POC, please let @guoger or me known in this channel if you are interested in joining the call. We are thinking of Wednesday (US folks: 8am PST, 11 am EST, London: 4 pm, China: 12AM)

harsha (Tue, 19 Dec 2017 03:58:07 GMT):
I'm interested to learn about this PoC. Please count me in.

guoger (Tue, 19 Dec 2017 03:59:04 GMT):
@harsha great! what time zone are you in? we are waiting for folks to have a consensus on this

harsha (Tue, 19 Dec 2017 03:59:14 GMT):
@guoger IST

guoger (Tue, 19 Dec 2017 04:00:09 GMT):
alright, then proposed time should work for you :)

zhishui (Tue, 19 Dec 2017 08:10:20 GMT):
Has joined the channel.

guoger (Tue, 19 Dec 2017 09:45:51 GMT):
@muralisr after quite some debugging, I found that I wasn

guoger (Tue, 19 Dec 2017 09:45:51 GMT):
@muralisr after quite some debugging, I found that I wasn't updating `stub` for a new `invoke`. Basically I was using the same `stub` when evmscc is init'ed, which obviously contains a stale txid.. stupid mistake

guoger (Tue, 19 Dec 2017 09:52:14 GMT):
but just to get this clear, - when `evmscc` is invoked, it has a `chaincode.Handler` associated with it, where `handler.txCtx` has key `mychannel+txid` - `evmscc` invokes `lscc`, a new instance of handler is created and associated with `lscc`, where `handler.txCtx` has exactly same key `mychannel+txid` - invocation to `lscc` is finished, and that tx context is deleted basically, for each chaincode, there will be a handler associated with it. If multiple chaincodes work together to complete one tx, all of them should have same key (channel name + txid) in their own instance of handler, correct?

muralisr (Tue, 19 Dec 2017 14:17:40 GMT):
@guoger can you elaborate on `evmscc invokes lscc` please ? How does it invoke and why ?

muralisr (Tue, 19 Dec 2017 14:22:08 GMT):
@swetha i'd like to join the call ... maybe a bit late though (but will try to be on time at 11EST)

guoger (Tue, 19 Dec 2017 15:18:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=i4ZcBsC5DB6joHR8i) @muralisr when new contract is installed, bytecode actually is stored in `lscc` namespace. So our `evmscc` needs to call `lscc` to retrieve the code and execute

guoger (Tue, 19 Dec 2017 15:19:27 GMT):
and it does ``` res := stub.InvokeChaincode("lscc", [][]byte{[]byte(lscc.GETDEPSPEC), []byte(stub.GetChannelID()), ccName}, stub.GetChannelID()) ```

muralisr (Tue, 19 Dec 2017 16:03:06 GMT):
@guoger I'd have stored the bytes directly in evmscc ...this would be along the lines of the "dynamic chaincode" approach we touched upon in the hackfest. The lscc is used by the fabric to manage its chaincode and execute them . Here the evmscc is executing it and seems more natural storing the code in evmscc ... you;d also avoid a InvokeChaincode call (could become expensive if you do it often enough)

muralisr (Tue, 19 Dec 2017 16:03:06 GMT):
@guoger I'd have stored the bytes directly in evmscc ...this would be along the lines of the "dynamic chaincode" approach we touched upon in the hackfest. The lscc is used by the fabric to manage its chaincode and execute them . Here the evmscc is executing code directly and seems more natural storing the code in evmscc directly as well ... you;d also avoid a InvokeChaincode call (could become expensive if you do it often enough)

muralisr (Tue, 19 Dec 2017 16:03:06 GMT):
@guoger I'd have stored the bytes directly in evmscc namespace...this would be along the lines of the "dynamic chaincode" approach we touched upon in the hackfest. The lscc is used by the fabric to manage its chaincode and execute them . Here the evmscc is executing code directly and seems more natural storing the code in evmscc directly as well ... you;d also avoid a InvokeChaincode call (could become expensive if you do it often enough). Also you;d avoid dragging lscc RWset into the TX

muralisr (Tue, 19 Dec 2017 16:06:40 GMT):
ie, in otherwords, evmscc will support an "install" verb directly

muralisr (Tue, 19 Dec 2017 17:11:45 GMT):
but to answer your question `basically, for each chaincode, there will be a handler associated with it. If multiple chaincodes work together to complete one tx, all of them should have same key (channel name + txid) in their own instance of handler, correct?` - yes, that's correct

tkuhrt (Tue, 19 Dec 2017 17:14:28 GMT):
@swetha : If you let me know the details of the call, I can add it to the Hyperledger community calendar.

swetha (Tue, 19 Dec 2017 17:28:21 GMT):
@tkuhrt: That would be great! I think the time is confirmed at US folks: 8am PST, 11 am EST, London: 4 pm, China: 12AM. Currently I am planning on using a Google Hangout: https://hangouts.google.com/call/KP2JqvS0tCDent7vmmmJAAEE. The tool we use may change.

tkuhrt (Tue, 19 Dec 2017 17:28:52 GMT):
Okay...let me know if it changes. I will add the details listed above.

tkuhrt (Tue, 19 Dec 2017 17:32:48 GMT):
Added to the calendar. It would be great if the meeting could be recorded for others to watch later.

swetha (Tue, 19 Dec 2017 18:39:39 GMT):
@tkuhrt, Thats a great idea. I will definitely keep that in mind

swetha (Tue, 19 Dec 2017 19:12:19 GMT):
@tkuhrt: Set up a webex meeting instead so we can record it. Here is the link: https://ibm.webex.com/ibm/j.php?MTID=m6d206b302a34a8d806c107c5b370ba53, Meeting Password is fabricevm Video address: Dial 928304252@ibm.webex.com Audio connection: +1-669-234-1178 United States of America Toll +1-669-234-1178 United States of America Toll Global call-in numbers Show toll-free dialing restrictions Access code: 928 304 252

tkuhrt (Tue, 19 Dec 2017 19:14:10 GMT):
Great! I updated the calendar entry. I am looking forward to the recording (as I have a conflict at this time).

sheehan (Wed, 20 Dec 2017 16:20:46 GMT):
Has joined the channel.

rtemprano (Wed, 20 Dec 2017 16:53:24 GMT):
Has joined the channel.

swetha (Wed, 20 Dec 2017 17:41:32 GMT):
@tkuhrt: Is the a place l can upload recording from the meeting this morning?

tkuhrt (Wed, 20 Dec 2017 17:43:48 GMT):
Yes...let me grant you access to a Google Drive folder...I will DM you

swetha (Wed, 20 Dec 2017 17:43:54 GMT):
Thanks!

tkuhrt (Wed, 20 Dec 2017 20:29:16 GMT):
Swetha uploaded the recording from this morning's demo to: https://drive.google.com/open?id=149FI5gEHLXAN7plzOCBUOyPB_s9AqPAj. Nice job, Swetha and Jay.

swetha (Wed, 20 Dec 2017 23:52:02 GMT):
@guoger & @silasdavis: I have my initial json rpc server code in this repo: https://github.com/swetharepakula/fabric-chaincode-evm/tree/poc-evm-fab-6590 under the `ethserver` dir

silasdavis (Thu, 21 Dec 2017 10:47:41 GMT):
@swetha thanks for sharing

silasdavis (Thu, 21 Dec 2017 10:50:35 GMT):
I think we should consider using a json-rpc library to take care of the JSON-RPC details such as: https://github.com/ybbus/jsonrpc

silasdavis (Thu, 21 Dec 2017 11:00:42 GMT):
I had a look at your demo (well done), I only skimmed it but you lay out the option to a) wrapping burrow, and b) this evmscc chaincode wrapper, and that you took the latter. Can you just describe to me how this intergrates with Burrow exactly?

guoger (Thu, 21 Dec 2017 15:51:12 GMT):
@silasdavis hi, thanks for reviewing our demo! To answer your question, our intention, at least for now, is to integrate Burrow EVM only. Therefore, we took the evm library and wrapped it into _evmscc_ (system chaincode in Fabric) to execute contract bytecode. So we weren't really _wrapping Burrow_.

guoger (Thu, 21 Dec 2017 15:52:15 GMT):
this is the design doc we continuously work on https://docs.google.com/document/d/1xZfdtFiIFvHI7UZAze2xbm5hhgaDHGRBMusozKfpOck/edit?usp=sharing

guoger (Thu, 21 Dec 2017 15:53:25 GMT):
@tkuhrt actually it would be nice if you could pin this link or put it in the channel description :)

guoger (Thu, 21 Dec 2017 15:53:49 GMT):
(I don't have moderator permission to do so I guess)

tkuhrt (Thu, 21 Dec 2017 16:05:34 GMT):

tkuhrt (Thu, 21 Dec 2017 16:05:41 GMT):
guoger

tkuhrt (Thu, 21 Dec 2017 16:07:17 GMT):
swetha

tkuhrt (Thu, 21 Dec 2017 16:08:56 GMT):
The design doc we continuously work on https://docs.google.com/document/d/1xZfdtFiIFvHI7UZAze2xbm5hhgaDHGRBMusozKfpOck/edit?usp=sharing

tkuhrt (Thu, 21 Dec 2017 16:13:18 GMT):
Discuss the integration of the EVM with Hyperledger Fabric

swetha (Thu, 21 Dec 2017 17:32:14 GMT):
@silasdavis: I will start playing with that library. I am also looking into this library: https://github.com/gorilla/rpc

swetha (Thu, 21 Dec 2017 17:32:14 GMT):
@silasdavis: I will start playing with that library. I think the library is a client though. I am also looking into this json rpc server library: https://github.com/gorilla/rpc

silasdavis (Thu, 21 Dec 2017 18:58:24 GMT):
It looks like gorilla does have a package for json rpc 2.0 now: http://www.gorillatoolkit.org/pkg/rpc/v2/json2

silasdavis (Thu, 21 Dec 2017 18:59:05 GMT):
actually Burrow uses gorilla for websockets.

silasdavis (Thu, 21 Dec 2017 19:00:45 GMT):
also yes clearly you are right it's just a client

silasdavis (Thu, 21 Dec 2017 19:02:05 GMT):
by the way, this is my first bash at an intermediate interface for all of our RPC layers: https://github.com/hyperledger/burrow/blob/hypermarmot/rpc/service.go#L37-L70

silasdavis (Thu, 21 Dec 2017 19:03:15 GMT):
as in the outer RPC is given an instance of that and formulates the concrete RPC

silasdavis (Thu, 21 Dec 2017 19:03:20 GMT):
for example as in: https://github.com/hyperledger/burrow/blob/hypermarmot/rpc/tm/routes.go#L29-L76

silasdavis (Thu, 21 Dec 2017 19:05:22 GMT):
I doubt `Service` is quite right, but if we could iterate on that, possibly split it up so that it might be something you could implement as an service provider on top of fabric and then implement web3 on top of that it would mean we could share a web3 and other end-user APIs

silasdavis (Thu, 21 Dec 2017 19:07:25 GMT):
I don't know how viable it would be to make the signature of methods like `Subscribe` and `BroadcastTx` generic enough to be implemented by a Burrow and a Fabric (and a Sawtooth??) backend, but it would be interesting to at least considser

silasdavis (Thu, 21 Dec 2017 19:08:14 GMT):
obviously they are based on Burrow types now, but are meant to abstract away from the return types of the corresponding v0 and tm APIs (the two interfaces Burrow has)

swetha (Thu, 21 Dec 2017 19:57:45 GMT):
I like the sound of sharing the API libraries and just have an underlying interface that is build on top of. Your interface is a good starting point for me to see how well that will fit in with fabric. In terms of those methods `Subscribe` and `BroadcastTx`, you are right they probably have to be tailored to the backend they are talking to. But the concept of those methods are universal, so there probably is some way to make those more generic?

sstone1 (Wed, 27 Dec 2017 16:04:24 GMT):
Has joined the channel.

marc0o (Sat, 30 Dec 2017 19:30:59 GMT):
Has joined the channel.

guoger (Wed, 10 Jan 2018 09:58:43 GMT):
@binhn to echo the question you had during our demo > evm caller account should probably be used to check the ACL of cross-chaincode invocation My take on this is that the chain of invocation would take place in the same tx context, where original creator of proposal would be used to test ACL, therefore caller account is till ignorable. cc @muralisr

binhn (Wed, 10 Jan 2018 09:58:44 GMT):
Has joined the channel.

muralisr (Wed, 10 Jan 2018 13:21:51 GMT):
@guoger sure, we have other options too re ACL to make it more flexible which we can explore when we need

ArnabChatterjee (Fri, 12 Jan 2018 06:27:09 GMT):
Has joined the channel.

yash-ibm (Mon, 15 Jan 2018 12:04:44 GMT):
Has joined the channel.

tasmiya_n (Mon, 15 Jan 2018 12:05:47 GMT):
Has joined the channel.

jtclark (Fri, 19 Jan 2018 10:52:35 GMT):
Has joined the channel.

Brucepark (Sat, 20 Jan 2018 06:14:44 GMT):
Has joined the channel.

guoger (Mon, 22 Jan 2018 07:00:10 GMT):
just fyi, somebody posted in #burrow-contributors requesting for web3 support :)

silasdavis (Fri, 26 Jan 2018 10:30:42 GMT):
Hi @swetha, happy new year, just saw your commit here: https://github.com/swetharepakula/fabric-chaincode-evm/commit/97d19e22983ca29bfc1618dd29a6d6c98b758b89 I've been working a bit on my intermediate RPC layers - it would be good to talk about how we might share code on Web3. I also have some broader interest in building some kind of compatibility (quite what form I am still thinking through) between Seth, Fabric-EVM, and Burrow - in the sense of transaction mappability and bridging of networks around the lingua franca of the EVM. This is something for the future but it would probably be good for me if I could understand a bit more about the architecture and ideally help write some code with you.

silasdavis (Fri, 26 Jan 2018 10:31:53 GMT):
Do you think it would be worth having a chat in voice to think through, in the first instance, a common 'Service Provider Interface' for web3?

swetha (Fri, 26 Jan 2018 17:33:42 GMT):
@silasdavis: Happy New Year to you too! Yes, I think have a discussion would be very helpful. What is usually a good time for you? @guoger @jtclark may want to join us too.

swetha (Fri, 26 Jan 2018 17:33:42 GMT):
@silasdavis: Happy New Year to you too! Yes, I think having a discussion would be very helpful. What is usually a good time for you? @guoger @jtclark may want to join us too.

silasdavis (Fri, 26 Jan 2018 17:37:29 GMT):
Ah yes in my head that was addressed to all three of you - but we had spoken about the SPI thing before. I keep a fairly random schedule within UTC waking hours (which tends to be heavily baby influenced). 10 am EST?

swetha (Fri, 26 Jan 2018 17:38:05 GMT):
Sure that should work for all of us. I will send out an invite next week

guoger (Sat, 27 Jan 2018 01:50:22 GMT):
works for me!

silasdavis (Mon, 29 Jan 2018 14:22:48 GMT):
Cool, noted you will do invite, Monday is only day I can't do currently

swetha (Mon, 29 Jan 2018 18:30:07 GMT):
@silasdavis, will Wednesday work?

silasdavis (Mon, 29 Jan 2018 19:17:55 GMT):
Sorry I didn't process that next week was this week when you sent it. I could do Thursday this week.

swetha (Mon, 29 Jan 2018 22:25:43 GMT):
Oh that is okay, would next week be better?

swetha (Mon, 29 Jan 2018 22:25:43 GMT):
Oh that is okay, would next week be better? @silasdavis

swetha (Mon, 29 Jan 2018 22:25:43 GMT):
Oh that is okay, would next week (first week of Feb) be better? @silasdavis

silasdavis (Tue, 30 Jan 2018 17:43:09 GMT):
yeah that would work better thans

swetha (Tue, 30 Jan 2018 17:48:25 GMT):
Cool, I will set up something in the first week of Febuary

swetha (Wed, 31 Jan 2018 00:59:56 GMT):
@adamludvik Would you be interested in the above ^^

adamludvik (Wed, 31 Jan 2018 00:59:57 GMT):
Has joined the channel.

adamludvik (Wed, 31 Jan 2018 21:27:44 GMT):
@swetha yes, I would be

guoger (Thu, 01 Feb 2018 01:18:35 GMT):
@muralisr I'm trying to see how `init` could fit in Ethereum model... not sure if Ethereum has this notion of _constructor_

muralisr (Thu, 01 Feb 2018 01:19:25 GMT):
@guoger you don't HAVE to implement anything in the `Init`

muralisr (Thu, 01 Feb 2018 01:20:09 GMT):
when the chaincode comes up first time it gives you an opportunnuty to store some state (typically some metadata)

muralisr (Thu, 01 Feb 2018 01:20:09 GMT):
when the chaincode is instantiated it gives you an opportunnuty to store some state (typically some metadata)

muralisr (Thu, 01 Feb 2018 01:20:44 GMT):
so for your purpose you can just return success from Init without doing anything

guoger (Thu, 01 Feb 2018 01:21:33 GMT):
yeah, that's what I have for now

muralisr (Thu, 01 Feb 2018 01:21:53 GMT):
ok

guoger (Thu, 01 Feb 2018 01:21:55 GMT):
thx!

muralisr (Thu, 01 Feb 2018 01:22:05 GMT):
anytime

guoger (Thu, 01 Feb 2018 01:23:00 GMT):
I pushed my draft patches out, starting from https://gerrit.hyperledger.org/r/#/c/17323/

guoger (Thu, 01 Feb 2018 01:23:36 GMT):
I haven't put you into reviewer list yet cuz I don't want to spam you with all email notification

guoger (Thu, 01 Feb 2018 01:24:23 GMT):
if you have some time, you are very welcome to comment on those :)

sheehan (Thu, 01 Feb 2018 01:39:56 GMT):
Ethereum contracts can have constructors. Is that somehow handled outside of `Init` in Fabric?

vchengsong (Thu, 01 Feb 2018 03:51:47 GMT):
Has joined the channel.

guoger (Thu, 01 Feb 2018 04:17:12 GMT):
@sheehan hi, thx for feedback! IIUC, constructors in ethereum contract, e.g. solidity, are called every time when it's loaded into an EVM (this is handled by burrow-evm). `init` in Fabric, on the other hand, is an one-time initialization. So I think the statement is correct > Is that somehow handled outside of `Init` in Fabric?

guoger (Fri, 02 Feb 2018 05:02:41 GMT):
@muralisr thanks for reviewing the patch! Without an extra field in CLI (and SDK), we will need to lookup _chaincode type_ in `lscc` for *every* invocation, incl. non-evm ones. I felt this is not very organic. What do you think? > We should not introduce a lang parameter to invoke/query just for doing an under the cover translation for EVM. Better be transparent and make users call "evmscc" directly and take the appropriate parameters directly as invoke args.

muralisr (Fri, 02 Feb 2018 14:33:15 GMT):
@guoger let me take a closer look and make sure I wasnt overlooking anything and then respond

muralisr (Fri, 02 Feb 2018 14:59:07 GMT):
│ │ └── cert.pem The way I understand it, you want to do something like `peer chaincode invoke -n mycc -l EVM -c '{"Args":["some", "args", "to", "the cc"]}'` which will internally convert it to call "evmcc" with args {"Args":["mycc", "some", "args", "to", "the cc"]} I'd just ask users to do this instead `peer chaincode invoke -n evmscc -c '{"Args":["mycc", "some", "args", "to", "the cc"]}' Perhaps I'm missing something @guoger ?

muralisr (Fri, 02 Feb 2018 14:59:07 GMT):
The way I understand it, you want to do something like `peer chaincode invoke -n mycc -l EVM -c '{"Args":["some", "args", "to", "the cc"]}'` which will internally convert it to call "evmcc" with args {"Args":["mycc", "some", "args", "to", "the cc"]} I'd just ask users to do this instead `peer chaincode invoke -n evmscc -c '{"Args":["mycc", "some", "args", "to", "the cc"]}'` Perhaps I'm missing something @guoger ?

muralisr (Fri, 02 Feb 2018 14:59:07 GMT):
The way I understand it, you want to do something like `peer chaincode invoke -n mycc -l EVM -c '{"Args":["some", "args", "to", "the cc"]}'` which will internally convert it to call "evmscc" with args {"Args":["mycc", "some", "args", "to", "the cc"]} I'd just ask users to do this instead `peer chaincode invoke -n evmscc -c '{"Args":["mycc", "some", "args", "to", "the cc"]}'` Perhaps I'm missing something @guoger ?

swetha (Fri, 02 Feb 2018 17:56:28 GMT):
@muralisr: I think what Jay mentioned above was to be able to do something like this: `peer chaincode invoke -n mycc -c '{"Args":["some", "args", "to", "the cc"]}'` where `mycc` is of type EVM bytecode

muralisr (Fri, 02 Feb 2018 17:57:26 GMT):
@swetha right, I understand... to make sure I;m not off my mark, would you agree `peer chaincode invoke -n evmscc -c '{"Args":["mycc", "some", "args", "to", "the cc"]}'` will work ?

muralisr (Fri, 02 Feb 2018 17:57:34 GMT):
or don't you think it won;t even work ?

muralisr (Fri, 02 Feb 2018 17:57:34 GMT):
or do you think it won;t even work ?

swetha (Fri, 02 Feb 2018 17:58:30 GMT):
I think that is a possible solution. I am considering on how that changes the user experience compared to a non evm chaincode

muralisr (Fri, 02 Feb 2018 17:58:37 GMT):
right

muralisr (Fri, 02 Feb 2018 17:58:38 GMT):
ok

muralisr (Fri, 02 Feb 2018 17:58:42 GMT):
we are on the same page then

swetha (Fri, 02 Feb 2018 17:59:03 GMT):
We can definitely make the `evmscc` chaincode invoke function operate in that way

muralisr (Fri, 02 Feb 2018 17:59:16 GMT):
currently we do have many situations where we call system chaincodes directly

muralisr (Fri, 02 Feb 2018 17:59:23 GMT):
typically "qscc"

muralisr (Fri, 02 Feb 2018 18:00:31 GMT):
a user csan just wrap `peer chaincode invoke -n evmscc -c '{"Args":["mycc", "some", "args", "to", "the cc"]}'` in a shellscript or something (evminvoke.sh) and hide the `evmscc`

muralisr (Fri, 02 Feb 2018 18:01:08 GMT):
we should avoid special casing and wrapping and start a precedent

swetha (Fri, 02 Feb 2018 18:07:09 GMT):
Doesn't this also act as a special case though? In all the other chaincodes you are directly calling the chaincode you wish to use. So a user would have to remember that `evm` bytecode is different. I don't think it is the same situation as using the `qscc` because that is meant for users to invoke when querying the ledger. Saying all of that, I do prefer a solution where we don't add a language flag. just not sure that directly sending calls to the `evmscc` is a better approach.

swetha (Fri, 02 Feb 2018 18:08:46 GMT):
But for now, at least initially, I am okay with users have to directly call `evmscc`. We can always change that in the future. We don't get that ability if we add the language flag. It would not be as easy to remove

swetha (Fri, 02 Feb 2018 18:08:46 GMT):
But for now, I am okay with users have to directly call `evmscc`. We can always change that in the future. We don't get that ability if we add the language flag. It would not be as easy to remove

muralisr (Fri, 02 Feb 2018 18:41:40 GMT):
I don't thnk of it as "special case" ... it may be a question of semantics. we can think of the evmscc VM _as_ the chaincode and it manages some code ("mycc")

muralisr (Fri, 02 Feb 2018 18:41:40 GMT):
I don't thnk of it as "special case" ... it may be a question of semantics. we can think of the evmscc _as_ the chaincode and it manages some code ("mycc")

muralisr (Fri, 02 Feb 2018 18:42:00 GMT):
but sure, we can revisit later

guoger (Sun, 04 Feb 2018 13:07:28 GMT):
Sorry for late response... I'm more inclined to be as close to Fabric semantics as possible, where > user installs a chaincode `mycc`, and then invokes it instead of > user installs a chaincode `mycc`, keep track of the type of it, and look it up when it makes a chaincode invocation. From a pure Ehereum DApp point of view, we could always translate *all* the invocations to `emvscc` calls in web3 adapter. However, if user may install all different type of chaincode, then it's an overhead for user

guoger (Sun, 04 Feb 2018 13:07:32 GMT):
cc @muralisr @swetha

guoger (Sun, 04 Feb 2018 13:07:32 GMT):
what do you think? cc @muralisr @swetha

muralisr (Sun, 04 Feb 2018 13:28:22 GMT):
@guoger in the original spirit of not modifying fabric (and adding evm specific code to CLI falls into that category) I'd say lets not do that for now. as @swetha points out, easy enough to add it later if that;s the right thing to do but hard to remove once its in

muralisr (Sun, 04 Feb 2018 13:44:54 GMT):
as long as we keep changes only to the EVM platfrom and evmscc and rest of the fabric untouched...

guoger (Sun, 04 Feb 2018 14:29:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=kdgkHdoSKXjzZPP3B) @muralisr had a very brief discussion with @muralisr , for our first MVP (let's call it phase 1), we probably should keep Fabric code as untouched as possible, even though it may twist developer experience a bit, i.e. user needs to keep track of types of installed chaincode, and for `evm` chaincode, it needs to explicitly call `evm`

guoger (Sun, 04 Feb 2018 14:29:59 GMT):
cc @swetha

muralisr (Sun, 04 Feb 2018 15:39:55 GMT):
@guoger `user needs to keep track of types of installed chaincode` - user does not need the `type of chaincode` (golang, java, etc) at the the time of invoke/query as you are just passing args to the running chaincode. ... unless you are thinkibg of something else which I;m missing. In any case, this does seem to be a good compromise for now

swetha (Sun, 04 Feb 2018 20:28:34 GMT):
@muralisr, the user will have to keep track that for evm chaincodes calls must go to the `evmscc` and the chaincode. So user doesn't have to worry about all other types, just `evm` type

guoger (Mon, 05 Feb 2018 01:33:38 GMT):
@muralisr yup, users need to at least keep track of evm chaincodes so that they know when to call `evmscc` directly. (obviously for those who use Fabric to run evm code *only*, it's not necessary)

guoger (Mon, 05 Feb 2018 02:43:05 GMT):
also [https://github.com/guoger/fabric/blob/FAB-6590-evm/core/endorser/endorser.go#L156|this part] is quite necessary because we need to *avoid launching evm chaincode*, and dispatch this into `evmscc` instead

guoger (Mon, 05 Feb 2018 02:43:05 GMT):
also [this part|https://github.com/guoger/fabric/blob/FAB-6590-evm/core/endorser/endorser.go#L156] is quite necessary because we need to *avoid launching evm chaincode*, and dispatch this into `evmscc` instead

guoger (Mon, 05 Feb 2018 02:43:05 GMT):
also [this part](https://github.com/guoger/fabric/blob/FAB-6590-evm/core/endorser/endorser.go#L156) is quite necessary because we need to *avoid launching evm chaincode*, and dispatch this into `evmscc` instead

guoger (Mon, 05 Feb 2018 09:08:11 GMT):
We thought about storing evm bytecode into ledger so `evmscc` doesn't need to consult `lscc` for the bytecode for every invocation. However, this doesn't work: - during instantiation, `lscc` writes `ChaincodeData` with name `mycc` - `evmscc` writes bytecode to ledger under namespace `evmscc` - during validation, [this check](https://github.com/hyperledger/fabric/blob/master/core/scc/vscc/validator_onevalidsignature.go#L432) would fail We probably have 3 options here: - if it's evm chaincode, use _evmscc_ as `ChaincodeData.Name` instead of _mycc_. (very hacky) - during invocation, check if bytecode exists in `evmscc` ledger, if not, query `lscc` for bytecode and store it in ledger (cache bytecode) - rollback to what we had for PoC, where `evmscc` consults `lscc` for every invocation (overhead, but works)

guoger (Mon, 05 Feb 2018 09:08:56 GMT):
I'm more inclined towards the third, and mark the second as future improvement

guoger (Mon, 05 Feb 2018 09:09:20 GMT):
cc @swetha

swetha (Mon, 05 Feb 2018 19:00:57 GMT):
@guoger: I agree with you. Lets stick with 3 for now, and then we can improve to the second option as a future improvement

guoger (Tue, 06 Feb 2018 08:46:17 GMT):
update the patch

guoger (Tue, 06 Feb 2018 08:46:17 GMT):
updated the patch

silasdavis (Wed, 07 Feb 2018 10:18:47 GMT):
@swetha @guoger @jtclark just to let you know I've had a stomach bug all night. I think there's a chance I'll rally by the time its our meeting, but just to give you a head's up I might not be able to make it

guoger (Wed, 07 Feb 2018 10:49:58 GMT):
@silasdavis no worries! take care! btw, if you have a quick answer to the question I posted in #burrow-contributors , I'd appreciate it :)

jtclark (Wed, 07 Feb 2018 12:56:17 GMT):
@silasdavis yes, please feel better :-)

silasdavis (Wed, 07 Feb 2018 14:21:12 GMT):
Thanks all I just woke up - feeling a little fuzzy - but I'd like to go ahead with the call just to get things rolling @guoger I'll take a look at that later my PM

swetha (Wed, 07 Feb 2018 15:23:54 GMT):
@silasdavis https://github.com/hyperledger/fabric-sdk-go/blob/master/api/apitxn/chclient/chclient.go#L66-L87

silasdavis (Wed, 07 Feb 2018 15:24:55 GMT):
Some EVM info: https://github.com/pirapira/awesome-ethereum-virtual-machine

silasdavis (Wed, 07 Feb 2018 15:30:34 GMT):
Solidity/EVM compatibility issue we are working through: https://github.com/hyperledger/burrow/issues/674

silasdavis (Wed, 07 Feb 2018 15:32:07 GMT):
Test cases: https://github.com/monax/bosmarmot/tree/master/monax/tests

silasdavis (Wed, 07 Feb 2018 15:35:49 GMT):
@jtclark https://github.com/monax/bosmarmot/tree/master/test

rjones (Mon, 12 Feb 2018 20:06:28 GMT):
Has left the channel.

eclairamb (Sat, 17 Feb 2018 17:59:55 GMT):
Has joined the channel.

yzhivkov (Sun, 25 Feb 2018 18:33:28 GMT):
Has joined the channel.

kakuzu (Mon, 26 Feb 2018 20:10:17 GMT):
Has joined the channel.

wrannaman (Mon, 26 Feb 2018 21:04:32 GMT):
Has joined the channel.

guoger (Tue, 27 Feb 2018 09:26:08 GMT):
I think we do need the concept of *accounts* for evm integration. Take the voting app here as an example: https://solidity.readthedocs.io/en/develop/solidity-by-example.html#voting when chair person assigns the _right to vote_ to a voter, it actually looks up and update variables using voter's address as the key. And when that actual voter invokes `vote`, the contract checks `msg.sender` to retrieve caller's address, which is used to lookup the map. This can be depicted by following code snippet: ``` struct Voter { uint weight; // weight is accumulated by delegation bool voted; // if true, that person already voted address delegate; // person delegated to uint vote; // index of the voted proposal } /// Give your vote (including votes delegated to you) /// to proposal `proposals[proposal].name`. function vote(uint proposal) public { Voter storage sender = voters[msg.sender]; require(!sender.voted); sender.voted = true; sender.vote = proposal; // If `proposal` is out of the range of the array, // this will throw automatically and revert all // changes. proposals[proposal].voteCount += sender.weight; } ``` I synced up with @swetha today and noticed that to introduce token in Fabric, accounts are also required. In our current poc, we follow the pattern of burrow to *compute account address from public key*, which can be retrieved using `stub.GetCreator()`. I wonder where we could track the effort of token work, and align the design cc @cbf @mastersingh24 @swetha

mastersingh24 (Tue, 27 Feb 2018 09:26:09 GMT):
Has joined the channel.

cbf (Tue, 27 Feb 2018 12:26:53 GMT):
+1 I think that any token support would need an account. It seems to me to be fundamental in many use cases.

silasdavis (Tue, 27 Feb 2018 13:25:11 GMT):
If the Ethereum world view is anything, it is account(/public key identity)-oriented programming... The `SENDER` and `ORIGIN` opcodes are the way the EVM exposes this. You can and do often build your own domain accounts on top - very often in the case of 'wallet' contracts, such as multisig wallets or just general purpose delegates that have more structure than the native account model (same flavour as @guoger's `Voter` example) - but you still end up tethering those to collections of native accounts since they are the signed source of transactions... I know this has come up before, but I've not fully understood how you are doing without accounts now...?

salmanbaset (Tue, 27 Feb 2018 13:59:08 GMT):
Has joined the channel.

swetha (Tue, 27 Feb 2018 17:34:25 GMT):
@silasdavis,currently our poc we are limited in the types of contracts we can use. We create an address based on the user's public key, but there is no account associated with the address. Anything that refers back to users becomes a problem. So we are rethinking that piece now

chandrakanthm (Wed, 28 Feb 2018 09:54:12 GMT):
Has joined the channel.

guoger (Thu, 01 Mar 2018 06:38:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=eeMyqrQQRJhxWqCn9) @cbf I wonder if there's an ongoing effort that we could join?

cbf (Thu, 01 Mar 2018 12:38:48 GMT):
none has been started, I would suggest a proposal be drafted to start the discussion

igetgames (Fri, 02 Mar 2018 17:41:53 GMT):
Has joined the channel.

wrannaman (Fri, 02 Mar 2018 22:29:16 GMT):
@guoger I'd be interested in helping draft that if you have some thoughts. Initially I was thinking of putting a spec together for a native token to fabric but it seems like the EVM integration has more momentum.

swetha (Fri, 02 Mar 2018 23:22:42 GMT):
@wrannaman : That would be great! The EVM integration design doc is here: https://docs.google.com/document/d/1xZfdtFiIFvHI7UZAze2xbm5hhgaDHGRBMusozKfpOck/edit?usp=sharing We were talking about starting another proposal doc specific to adding accounts to Fabric. I will send that to you once it is started. Probably early next week. Unless you already have something, we would love to work off of what you already have.

dave.enyeart (Tue, 06 Mar 2018 17:05:02 GMT):
Has joined the channel.

rjones (Tue, 06 Mar 2018 18:12:41 GMT):
dave.enyeart

guoger (Thu, 08 Mar 2018 03:47:02 GMT):
@mastersingh24 I overheard that you guys are planning to change some of system chaincodes, e.g. `lscc` to be plugin. Is it being worked on? We have a problem while writing `evm chaincode` as system chaincode plugin, and I assume you guys would face the same: - Both `fabric` and `fabric-cc` probably depend on a common pkg, let's say `pkgA`. - `fabric-cc` sits in a different repo as `fabric`, you need to vendor `pkgA` for both of them. - then you compile `fabric-cc` to .so lib, it wraps all the dependencies into it, including `pkgA`. - `fabric` loads `pkgA` - `fabric` loads `fabric-cc.so`, which also loads `pkgA`, which is a new instance of it other than the one in previous step Then we end up loading `pkgA` twice. In our case, we have this `golang.org/x/net/trace`, which registers to an endpoint `/Debug/requests`, and the second attempt would panic due to double-registration.

guoger (Thu, 08 Mar 2018 03:48:29 GMT):
I wonder how you guys plan to solve this problem? We are thinking we could have `fabric-cc` as a git submodule in `fabric` repo, so they would share the same `vendor`. However, this is still inconvenient cuz every time `fabric-cc` needs a new dependency, it needs to be vendored into `fabric`/vendor

guoger (Thu, 08 Mar 2018 03:48:36 GMT):
cc @swetha

guoger (Thu, 08 Mar 2018 03:48:36 GMT):
cc @swetha @muralisr

CodeReaper (Sun, 18 Mar 2018 17:26:20 GMT):
Has joined the channel.

robinrob (Mon, 19 Mar 2018 22:16:30 GMT):
Has joined the channel.

ShikarSharma (Tue, 20 Mar 2018 22:43:04 GMT):
Has joined the channel.

sharifahmad2061 (Wed, 21 Mar 2018 17:39:48 GMT):
Has joined the channel.

cbf (Sat, 31 Mar 2018 21:09:48 GMT):
@guoger @swetha I need to demo the fabric-evm code for an analyst briefing on Tuesday

cbf (Sat, 31 Mar 2018 21:09:48 GMT):
@guoger @swetha I'd like to demo the fabric-evm code for an analyst briefing on Tuesday

cbf (Sat, 31 Mar 2018 21:09:56 GMT):
is it in operational shape?

cbf (Sat, 31 Mar 2018 21:10:39 GMT):
I could edit the video down if needed, but doing other fabric and composer live so...

guoger (Mon, 02 Apr 2018 09:47:33 GMT):
@cbf yes, we have both `evm` and `web3` ready for a live demo. We will come up with a complete instruction for you today.

cbf (Mon, 02 Apr 2018 11:04:16 GMT):
you guys rock! ;-)

swetha (Tue, 03 Apr 2018 07:03:06 GMT):
@cbf: We ran into issues for showing `web3`. The most recent `web3` library has API changes, so we don't have those instructions ready yet. If you want to run an e2e test you use this: https://github.com/swetharepakula/fabric/tree/master/examples/first-network. If you want to demo using the peer cli you can follow these instructions: https://github.com/swetharepakula/fabric/blob/master/core/scc/evmscc/Instructions.md. cc/ @guoger

cbf (Tue, 03 Apr 2018 11:17:13 GMT):
building now

guoger (Tue, 03 Apr 2018 11:26:05 GMT):
@cbf let me know if you run into problem

cbf (Tue, 03 Apr 2018 11:41:05 GMT):
I did, but I resolved;-)

cbf (Tue, 03 Apr 2018 11:42:05 GMT):
basically, I had old version of tools installed in my path (I need to fix that) and the byfn.sh path is incorrectly including ../bin but the build outputs to ../../.build/bin

cbf (Tue, 03 Apr 2018 11:42:31 GMT):
secondly, using 1.1, you need an updated configtx.yaml that includes the capabilities section

cbf (Tue, 03 Apr 2018 11:42:39 GMT):
I'll submit a patch

guoger (Tue, 03 Apr 2018 12:02:08 GMT):
@cbf sounds good! We were actually using e2e_cli for testing purpose and had evmscc implemented as plugin (you could follow steps here https://github.com/guoger/fabric-chaincode-evm to build and run it). However, Swetha had some problems building it, so we decided to go down a safer path for your demo and have evmscc embedded into Fabric

cbf (Tue, 03 Apr 2018 13:15:42 GMT):
so, you guys are tracking the pluggable ESCC yes? assume that will be the vehicle to get this merged/operational

cbf (Tue, 03 Apr 2018 13:17:20 GMT):
https://jira.hyperledger.org/browse/FAB-8729?jql=description%20~%20chaincode%20AND%20statusCategory%20!%3D%20Done%20AND%20type%20!%3D%20Bug%20ORDER%20BY%20updated%20DESC

cbf (Tue, 03 Apr 2018 13:17:20 GMT):
https://jira.hyperledger.org/browse/FAB-8729

cbf (Tue, 03 Apr 2018 13:19:03 GMT):
yacov would have more details

guoger (Tue, 03 Apr 2018 14:21:44 GMT):
oh, we were aware of this work but didn't really know much details. Although we did talk to divyank who helped us with Golang plugin and caveats

Rumeel_Hussain (Tue, 03 Apr 2018 15:03:48 GMT):
Has joined the channel.

cbf (Wed, 04 Apr 2018 11:50:45 GMT):
that is the path to getting this into 1.2 @swetha @guoger

cbf (Wed, 04 Apr 2018 12:11:08 GMT):
do me a favor and share with @yacovm the requirements you have for ESCC and VSCC to implement the pluggable EVMscc

yacovm (Wed, 04 Apr 2018 12:11:09 GMT):
Has joined the channel.

yacovm (Wed, 04 Apr 2018 12:11:44 GMT):
I have a recording of the next gen endorsement and validation

yacovm (Wed, 04 Apr 2018 12:11:48 GMT):
and a presentation

yacovm (Wed, 04 Apr 2018 12:11:50 GMT):
@guoger

cbf (Wed, 04 Apr 2018 12:11:54 GMT):
eg what capabilities you need

yacovm (Wed, 04 Apr 2018 12:12:01 GMT):
of the playback that was when I presented it

cbf (Wed, 04 Apr 2018 12:12:11 GMT):
@yacovm have you seen their current impl?

yacovm (Wed, 04 Apr 2018 12:12:18 GMT):
I haven't seen anything

yacovm (Wed, 04 Apr 2018 12:12:34 GMT):
also not sure who is "their"

cbf (Wed, 04 Apr 2018 12:12:50 GMT):
@guoger and @swetha https://chat.hyperledger.org/channel/fabric-evm?msg=uPoEAo4JNApLRZqDa

cbf (Wed, 04 Apr 2018 12:13:08 GMT):
also https://chat.hyperledger.org/channel/fabric-evm?msg=bmh3rd9378CJhymdJ

yacovm (Wed, 04 Apr 2018 12:13:53 GMT):
hmmm, Chris - I'm a bit overloaded these days so I think it'd make sense that the EVM guys would read the design of the pluggable ESCC and VSCC

yacovm (Wed, 04 Apr 2018 12:13:58 GMT):
and will contact me for issues

yacovm (Wed, 04 Apr 2018 12:14:03 GMT):
does that make sense?

yacovm (Wed, 04 Apr 2018 12:14:39 GMT):
they know better than I can hope to analyze their needs

cbf (Wed, 04 Apr 2018 12:14:54 GMT):
yes, I am not looking to have you do more... I am hoping that they can help you, so access to the spec would be ideal (I could not find it linked to the JIRA)https://jira.hyperledger.org/browse/FAB-8531

yacovm (Wed, 04 Apr 2018 12:15:22 GMT):
i linked it to the epic

yacovm (Wed, 04 Apr 2018 12:15:40 GMT):
oh wait

cbf (Wed, 04 Apr 2018 12:16:27 GMT):
ah, this is the problem with the 1.2 dashboard, epics are not included in the set of issues

cbf (Wed, 04 Apr 2018 12:16:30 GMT):
https://jira.hyperledger.org/browse/FAB-8729

yacovm (Wed, 04 Apr 2018 12:17:35 GMT):
@cbf https://jira.hyperledger.org/browse/FAB-8729

yacovm (Wed, 04 Apr 2018 12:17:41 GMT):
i linked it to here ^

yacovm (Wed, 04 Apr 2018 12:17:56 GMT):
i thought putting it on the epic makes most sense

yacovm (Wed, 04 Apr 2018 12:19:09 GMT):
also @simsc said he will upload my recording to youtube....

simsc (Wed, 04 Apr 2018 12:19:09 GMT):
Has joined the channel.

yacovm (Wed, 04 Apr 2018 12:19:17 GMT):
(any news on that btw? ;) )

cbf (Wed, 04 Apr 2018 12:30:00 GMT):
nope

yacovm (Wed, 04 Apr 2018 12:30:58 GMT):
I have the recording as a file, I can send it to anyone who wants...

cbf (Wed, 04 Apr 2018 12:34:31 GMT):
@yacovm operations flow seems to suffer the same issues as chaincode

yacovm (Wed, 04 Apr 2018 12:34:42 GMT):
nope

yacovm (Wed, 04 Apr 2018 12:34:53 GMT):
it compiles the stuff when you install it

yacovm (Wed, 04 Apr 2018 12:34:57 GMT):
not when you load it !

cbf (Wed, 04 Apr 2018 12:35:02 GMT):
installing the plugin on each peer

yacovm (Wed, 04 Apr 2018 12:35:09 GMT):
oh, that?

yacovm (Wed, 04 Apr 2018 12:35:15 GMT):
it is a hard requirement for me

cbf (Wed, 04 Apr 2018 12:35:15 GMT):
yes

yacovm (Wed, 04 Apr 2018 12:35:20 GMT):
I have nothing to do against that

yacovm (Wed, 04 Apr 2018 12:35:25 GMT):
we can discuss it offline

victer (Fri, 13 Apr 2018 11:54:26 GMT):
Has joined the channel.

Rednish (Tue, 17 Apr 2018 19:29:56 GMT):
Has joined the channel.

navaneethaa (Wed, 18 Apr 2018 10:47:07 GMT):
Has joined the channel.

Titret (Thu, 19 Apr 2018 00:53:23 GMT):
Has joined the channel.

hosemose (Tue, 24 Apr 2018 04:58:53 GMT):
Has joined the channel.

guoger (Tue, 24 Apr 2018 16:52:52 GMT):
review chain starts from https://gerrit.hyperledger.org/r/#/c/18667/

guoger (Tue, 24 Apr 2018 16:53:19 GMT):
@swetha feel free to push your cache changes into it

guoger (Tue, 24 Apr 2018 16:53:36 GMT):
and let's kickoff review process

cbf (Tue, 24 Apr 2018 20:05:53 GMT):
might be easier to separate the vendored gorp from our code in separate CRs

cbf (Tue, 24 Apr 2018 20:06:06 GMT):
vendor stuff first

cbf (Tue, 24 Apr 2018 20:07:06 GMT):
also, we probably should align with use of dep

cbf (Tue, 24 Apr 2018 20:07:51 GMT):
nevermind... I see you are

cbf (Tue, 24 Apr 2018 23:42:47 GMT):
I have some makefile additions once you've addressed my comments

cbf (Wed, 25 Apr 2018 11:54:12 GMT):
I piled on your makefile CR https://gerrit.hyperledger.org/r/c/20995/

cbf (Wed, 25 Apr 2018 11:54:16 GMT):
added linters

cbf (Wed, 25 Apr 2018 18:04:49 GMT):
@guoger thanks for the review, addressed comments https://gerrit.hyperledger.org/r/c/20995/

guoger (Thu, 26 Apr 2018 07:23:49 GMT):
@cbf @swetha rebased remaining patches and i think they are good to go

cbf (Thu, 26 Apr 2018 11:00:04 GMT):
@guoger https://gerrit.hyperledger.org/r/c/20961/6 is a "draft" and while it has all votes, cannot be merged

cbf (Thu, 26 Apr 2018 11:01:38 GMT):
https://gerrit.hyperledger.org/r/c/20963/ needs to be rebased

cbf (Thu, 26 Apr 2018 11:02:32 GMT):
I'll need to rebase mine on yours

guoger (Thu, 26 Apr 2018 12:35:25 GMT):
@cbf rebased

cbf (Thu, 26 Apr 2018 13:08:48 GMT):
I rebased again;-)

cbf (Thu, 26 Apr 2018 13:08:56 GMT):
ready to merge

cbf (Thu, 26 Apr 2018 13:10:02 GMT):
@guoger this is also ready for another +2

cbf (Thu, 26 Apr 2018 13:11:28 GMT):
this one is also ready now https://gerrit.hyperledger.org/r/c/20965

cbf (Fri, 27 Apr 2018 13:30:44 GMT):
I trust we are good for the review with design this morning?

guoger (Fri, 27 Apr 2018 13:34:47 GMT):
yup

cbf (Fri, 27 Apr 2018 13:38:26 GMT):
gr8

cbf (Fri, 27 Apr 2018 13:39:05 GMT):
btw, Marie Wieck wants a demo;-)

nickgaski (Fri, 27 Apr 2018 15:22:11 GMT):
Has joined the channel.

nickgaski (Fri, 27 Apr 2018 15:35:21 GMT):
so this works with vanilla solidity code? You don't have to code against the chaincode interface?

nickgaski (Fri, 27 Apr 2018 15:36:29 GMT):
It looks like the State Writer module of the evmscc handles the conversion... is that correct?

guoger (Fri, 27 Apr 2018 15:51:01 GMT):
@nickgaski we currently supports 0.4.x, and you would be writing pure Solidity code.

chainsaw (Fri, 27 Apr 2018 15:51:37 GMT):
Has joined the channel.

guoger (Fri, 27 Apr 2018 15:51:38 GMT):
State Writer piece is converting calls from Burrow EVM to Fabric cc apis

nickgaski (Fri, 27 Apr 2018 15:54:08 GMT):
thanks Jay. So in theory, could a single web3 application interface with the evmscc for state information on a Fabric channel and then proxy data to a deployed contract on ethereum main net or private chain?

guoger (Fri, 27 Apr 2018 16:23:55 GMT):
@nickgaski in theory yes. but the data would be bridged externally from fabric to others

guoger (Fri, 27 Apr 2018 16:24:46 GMT):
meaning two networks are still "isolated"

nickgaski (Fri, 27 Apr 2018 16:30:44 GMT):
right right. this is very cool work. nicely done

guoger (Fri, 27 Apr 2018 16:34:23 GMT):
thx!

cbf (Fri, 27 Apr 2018 19:16:56 GMT):
@nickgaski we are working on a web3 proxy server as well which translates web3 calls to go-sdk calls

nickgaski (Fri, 27 Apr 2018 19:21:53 GMT):
oh that's awesome. so you could set a `web3.provider` against a Fabric node.

nickgaski (Fri, 27 Apr 2018 19:22:46 GMT):
@cbf - are there weekly or bi-weekly meetings for this?

cbf (Fri, 27 Apr 2018 19:25:03 GMT):
nah, just this channel

cbf (Fri, 27 Apr 2018 19:25:28 GMT):
though I suppose @guoger and @swetha do hangouts a bit

cbf (Fri, 27 Apr 2018 19:25:48 GMT):
if you are interested in helping, glad to have it

cbf (Fri, 27 Apr 2018 19:26:24 GMT):
as for the web3.provider it would be to the proxy

cbf (Fri, 27 Apr 2018 19:26:40 GMT):
we are still debating best approach to handling the proxy

cbf (Fri, 27 Apr 2018 19:27:17 GMT):
initially, we think one account per proxy since it has the keys... we are exploring better options, too

cbf (Fri, 27 Apr 2018 19:28:16 GMT):
presently, we derive the ethereum acct from the user's certificate registered with msp

cbf (Fri, 27 Apr 2018 19:28:41 GMT):
@nickgaski ^^

nickgaski (Fri, 27 Apr 2018 19:34:33 GMT):
Thanks for the info Chris. This is some really exciting development. I'll continue pestering you guys on this channel and hopefully help out as I can.

cbf (Fri, 27 Apr 2018 19:35:26 GMT):
we'd love feedback from consensys

SjirNijssen (Tue, 01 May 2018 18:42:55 GMT):
Has joined the channel.

Aswath8687 (Tue, 01 May 2018 19:47:30 GMT):
Has joined the channel.

carlcraig (Tue, 01 May 2018 21:44:12 GMT):
Has joined the channel.

krisc 4 (Wed, 02 May 2018 03:30:37 GMT):
Has joined the channel.

kevin-s-wang (Thu, 03 May 2018 02:36:46 GMT):
Has joined the channel.

avlakshmy (Mon, 07 May 2018 12:49:31 GMT):
Has joined the channel.

avkrishnan (Tue, 08 May 2018 09:34:28 GMT):
Has joined the channel.

Starseven (Tue, 08 May 2018 11:56:16 GMT):
Has joined the channel.

JohnH_Traede (Thu, 10 May 2018 04:43:16 GMT):
Has joined the channel.

versus (Mon, 14 May 2018 09:05:41 GMT):
Has joined the channel.

soc1024 (Sat, 19 May 2018 23:08:10 GMT):
Has joined the channel.

soc1024 (Sat, 19 May 2018 23:08:22 GMT):
hi

soc1024 (Sat, 19 May 2018 23:18:49 GMT):
i'm writing some kind of multiparty cryptography application in Python, but I want to use fabric as the backend for a "broadcast" component of it

soc1024 (Sat, 19 May 2018 23:19:27 GMT):
it's easiest for me to express what i want using Solidity and test it using ethereumjs-testrpc, and I'm hoping it can just run easily on top of fabric-em

soc1024 (Sat, 19 May 2018 23:19:27 GMT):
it's easiest for me to express what i want using Solidity and test it using ethereumjs-testrpc, and I'm hoping it can just run easily on top of fabric-evm

soc1024 (Sat, 19 May 2018 23:19:27 GMT):
it's easiest for me to express what i want using Solidity and test it using ethereumjs-testrpc and web3, and I'm hoping it can just run easily on top of fabric-evm too

MenterQuick (Sun, 20 May 2018 06:14:48 GMT):
Has joined the channel.

guoger (Mon, 21 May 2018 01:43:45 GMT):
@soc1024 that's exactly the use case we'd like to address in this work. I would expect many hiccups though, as this work is still rudimentary, but we are more than happy to help you out!

soc1024 (Mon, 21 May 2018 01:45:45 GMT):
@guoger is there a recommended way to run a fabric instance with the evm framework loaded, maybe a simple docker thing? i am looking at https://github.com/swetharepakula/fabric/tree/FAB-6590-poc but do not see the relevant docs or something obvious

soc1024 (Mon, 21 May 2018 01:46:40 GMT):
and: cool, thanks!

guoger (Mon, 21 May 2018 03:03:59 GMT):
@soc1024 here's a peer image with evmscc embedded: `docker pull guoger/fabric-peer:evmscc-embedded`, with which you could launch a fabric network using docker-compose. that should give you a good starting point

guoger (Mon, 21 May 2018 04:26:40 GMT):
@jimthematrix hi Jim, saw your comment in JIRA and google doc, thanks a LOT! - that design doc is a bit outdated comparing to our current implementation w.r.t contract deployment. we indeed inspect `to` field to identify a contract deploy tx. - if we derive creator from org, instead of individual user, it does align with Fabric architecture. However it does not give a consistent experience to Eth developers. Again, we have not decided on this, and it may change when we finish the design of native accounts in Fabric. We are very much in need of help! I'll update the design doc to be more consistent with our implementation, as more people may be interested in this work.

jimthematrix (Mon, 21 May 2018 04:26:41 GMT):
Has joined the channel.

guoger (Mon, 21 May 2018 04:27:13 GMT):
also, this channel is where we discuss this integration, you are welcome to hang out here :)

cbf (Mon, 21 May 2018 12:56:58 GMT):
https://github.com/ConsenSys/Tokens <- contains some tests we might leverage

cbf (Mon, 21 May 2018 12:57:16 GMT):
another https://github.com/CryptoverseRocks/token-test-suite

cbf (Mon, 21 May 2018 12:57:29 GMT):
more https://github.com/OpenZeppelin/openzeppelin-solidity

cbf (Mon, 21 May 2018 13:03:00 GMT):
http://truffleframework.com/tutorials/building-dapps-for-quorum-private-enterprise-blockchains

cbf (Mon, 21 May 2018 14:49:11 GMT):
@swetha where is the code you use to derive an ethereum account id from our x509 certs?

swetha (Mon, 21 May 2018 16:17:00 GMT):
@cbf : https://github.com/hyperledger/fabric-chaincode-evm/blob/master/plugin/evmscc.go#L161-L178

swetha (Mon, 21 May 2018 16:17:18 GMT):
And that corresponds to the call `web3.eth.accounts`

cbf (Mon, 21 May 2018 16:41:52 GMT):
oh, interesting...

cbf (Mon, 21 May 2018 16:42:02 GMT):
ok, let me see if I understand correctly

cbf (Mon, 21 May 2018 16:43:06 GMT):
you have a call sent by a fabric account, that just sends the method 'account' and that returns the id string that is derived from the caller's certificate

cbf (Mon, 21 May 2018 16:43:15 GMT):
have I got that right?

cbf (Mon, 21 May 2018 16:44:44 GMT):
@swetha ^^

swetha (Mon, 21 May 2018 16:44:58 GMT):
Yes

swetha (Mon, 21 May 2018 16:45:33 GMT):
One thing we could do is repeat the code that we derive the account address in the proxy

cbf (Mon, 21 May 2018 16:45:49 GMT):
yes, I was thinking where we could leverage this

cbf (Mon, 21 May 2018 16:46:24 GMT):
the problem though is that if I have an ethereum wallet, it is going to sign with a different ec

swetha (Mon, 21 May 2018 16:46:28 GMT):
Once we introduce accounts into fabric, there also may be a better place/way to derive the account address

cbf (Mon, 21 May 2018 16:46:59 GMT):
I guess we could go with a model that we don't support wallets

cbf (Mon, 21 May 2018 16:47:10 GMT):
my concern though is that that is what will be expected

swetha (Mon, 21 May 2018 16:48:47 GMT):
I think we need to investigate further what is involved to supporting wallets, specifically ethereum ones

cbf (Mon, 21 May 2018 16:58:16 GMT):
yes

cbf (Mon, 21 May 2018 16:58:39 GMT):
also... thinking that we might want to explore a grpc provider?

cbf (Mon, 21 May 2018 16:58:47 GMT):
https://github.com/ethereum/web3.js/blob/develop/lib/web3/httpprovider.js

cbf (Mon, 21 May 2018 16:59:02 GMT):
that might be a bit much

cbf (Mon, 21 May 2018 16:59:04 GMT):
not sure

cbf (Mon, 21 May 2018 16:59:15 GMT):
we don't need to be all things

swetha (Mon, 21 May 2018 16:59:24 GMT):
Currently we do have that http provider, that is what the Proxy is

cbf (Mon, 21 May 2018 16:59:32 GMT):
yes

swetha (Mon, 21 May 2018 16:59:34 GMT):
What we could do next is support IPC

cbf (Mon, 21 May 2018 16:59:38 GMT):
but, replacing that

cbf (Mon, 21 May 2018 17:01:21 GMT):
nah... would need all the support in the proxy itself and still needs certs

cbf (Mon, 21 May 2018 17:29:56 GMT):
we need to think though some use cases

cbf (Mon, 21 May 2018 17:30:50 GMT):
if I have an account on public ethereum network... do I interact with it on fabric? seems to me only if we actually want to interop between the two

cbf (Mon, 21 May 2018 17:30:58 GMT):
not sure we are ready for thet

cbf (Mon, 21 May 2018 17:30:58 GMT):
not sure we are ready for that

swetha (Mon, 21 May 2018 17:38:28 GMT):
I agree, I am not sure we want to do that. I don't see much gain for the user

guoger (Tue, 22 May 2018 01:36:35 GMT):
> if I have an account on public ethereum network... do I interact with it on fabric? seems to me only if we actually want to interop between the two I'm thinking more of interconnecting two networks, e.g. Ethereum <=> Fabric, so the same transaction could be broadcasted to and processed by both network. Even better, if fabric could become the abstraction layer that glue multiple public network together.

guoger (Tue, 22 May 2018 01:37:34 GMT):
one obvious use case could be the exchange, which is kinda centralized today.

xixuejia (Tue, 22 May 2018 02:30:54 GMT):
Has joined the channel.

cbf (Tue, 22 May 2018 11:33:43 GMT):
yes

cbf (Tue, 22 May 2018 11:34:01 GMT):
this is what I meant by interop

cbf (Tue, 22 May 2018 13:14:18 GMT):
I just added new epic for the proxy service FAB-10273

cbf (Tue, 22 May 2018 13:15:12 GMT):
we need to build a development plan for that, but more importantly and urgently, we need to build a test plan for the plugin that includes running a broad range of solidity contracts and finding out what works and what doesn't

cbf (Tue, 22 May 2018 13:15:52 GMT):
because for 1.2, we will want to have a solid caveat on where we are so as not to leave people with unfulfilled expectations

jimthematrix (Tue, 22 May 2018 14:14:34 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=JK5cCR7NJWivRtyYa) @guoger thanks Jay. where can I find more details on the native accounts design for Fabric?

cbf (Tue, 22 May 2018 14:45:22 GMT):
_waves_

cbf (Tue, 22 May 2018 14:46:28 GMT):
@jimthematrix we haven't got a design yet

cbf (Tue, 22 May 2018 14:46:53 GMT):
would love input... have been exploring a few relevant specs etc

jimthematrix (Tue, 22 May 2018 14:48:29 GMT):
@cbf @guoger @swetha I read the code in the Swetha's repos and was getting the impression that it's trying to enable a "native" ethereum DApps developer experience by mocking (a subset of) the JSON-RPC APIs via the proxy server that one has to set up with the network config yaml. thinking back on Jay's response above whether the design should cater to a more "fabric-native" experience or "ethereum-native", my observation is that if we want to enable a truly ethereum native experience we would have to ask the developers to get unique certs for each ethereum accounts, and I think that can get really clunky (and scary) really quickly with all those certs to manage

jimthematrix (Tue, 22 May 2018 14:49:11 GMT):
(ah ok got it, thanks Chris for clarifying that)

cbf (Tue, 22 May 2018 14:55:10 GMT):
@jimthematrix yeah, if you look above, we've been discussing this

cbf (Tue, 22 May 2018 14:56:59 GMT):
on the one hand, enabling one to use any existing ethereum account in fabric would be great... but it means we need to implement the bitcoin crypto in the msp for signing and validation

jimthematrix (Tue, 22 May 2018 14:57:01 GMT):
I think until ethereum introduces org accounts, the current expectation is each transaction can be signed with any random key and it's up to the smart contract to enforce ACL with msg.sender. i wonder if a new MSP impl is in order to accommodate this kind of paradigm

jimthematrix (Tue, 22 May 2018 14:57:33 GMT):
ha I think we are saying the same thing

cbf (Tue, 22 May 2018 14:57:49 GMT):
well, cannot be rando sig... was thinking we wanted it to be registered

cbf (Tue, 22 May 2018 14:58:38 GMT):
now, what we were also thinking (well, at least me) is that we could take the id of the account and register that, generating a fabric-specific certificate

jimthematrix (Tue, 22 May 2018 14:58:39 GMT):
that can be difficult, with popular client side deterministic key derivation techniques like HD Wallet, each transaction can be signed with a different key

cbf (Tue, 22 May 2018 14:59:16 GMT):
yeah, different thing

cbf (Tue, 22 May 2018 14:59:26 GMT):
that's like our idemix

jimthematrix (Tue, 22 May 2018 15:00:02 GMT):
"well, cannot be rando sig" - that's the main difference in how ethereum treats identities (until there's org identities) vs. fabric.

jimthematrix (Tue, 22 May 2018 15:00:41 GMT):
in ethereum it's really any private key can send transactions and the nodes will happily take them and pass it on to the smart contracts to decide what to do with them

jimthematrix (Tue, 22 May 2018 15:00:55 GMT):
even Quorum works the same way

jimthematrix (Tue, 22 May 2018 15:05:07 GMT):
fabric could certainly enforce a more organized setup and require keys to be registered first, and issue certs for them, maybe through an authenticated fabric-ca client

jimthematrix (Tue, 22 May 2018 15:06:58 GMT):
"we need to implement the bitcoin crypto in the msp for signing and validation" - this would simply be validating that the signature matches the public key, there's no validating of the identity itself like with PKI certs in fabric today

cbf (Tue, 22 May 2018 15:24:39 GMT):
right, quorum is just permissioned vis who can run a node

cbf (Tue, 22 May 2018 15:24:46 GMT):
that really isn't full permissioning

cbf (Tue, 22 May 2018 15:25:00 GMT):
you cannot just hide behind a firewall

cbf (Tue, 22 May 2018 15:26:26 GMT):
right, so I was looking at using fabric-ca-client exactly

ahmadzafar (Tue, 22 May 2018 16:25:41 GMT):
Has joined the channel.

swetha (Tue, 22 May 2018 17:37:08 GMT):
@cbf @guoger @jimthematrix : Though this document is far from complete, Jay and I had started a proposal document to have single place to write down our thoughts: https://docs.google.com/document/d/1mrIgx-GLMRwMKbs04PoDPuqUUt56kpaz1o419sMfbe4/edit?usp=sharing

swetha (Tue, 22 May 2018 17:40:49 GMT):
There is not much design in there yet, more of why we wanted to introduce accounts

cbf (Tue, 22 May 2018 17:41:41 GMT):
;-)

cbf (Tue, 22 May 2018 17:42:00 GMT):
so, balances and storing the account... I think that needs to be in MVP

cbf (Tue, 22 May 2018 17:43:27 GMT):
I need to give more thought, but seems to me that any interest is going to be predicated on being able to run erc contracts

cbf (Tue, 22 May 2018 17:43:58 GMT):
thoughts?

cbf (Tue, 22 May 2018 17:45:50 GMT):
btw, one of the early adopters wants us to add gas back!

swetha (Tue, 22 May 2018 17:47:43 GMT):
Yes I do think being able to run erc contracts is important. It sounded like people were interested in that last week.

swetha (Tue, 22 May 2018 17:48:37 GMT):
Do they want gas back in the sense they want to configure how much gas per transaction or they want to give accounts a certain amount of gas at a time to rate limit the number of transactions they can run

cbf (Tue, 22 May 2018 18:00:38 GMT):
yes

cbf (Tue, 22 May 2018 18:00:41 GMT):
exactly

cbf (Tue, 22 May 2018 18:01:20 GMT):
I think that we can finagle that for 1.3 but it will be a requirement for one of our sponsor users

cbf (Tue, 22 May 2018 18:01:51 GMT):
my understanding is that the idea is that gas will be doled out

cbf (Tue, 22 May 2018 18:02:05 GMT):
so it can be used to rate-limit the system generally

cbf (Tue, 22 May 2018 18:03:14 GMT):
so, with regards to balances... I'm coming up to speed but it seems that token balances are maintained in the token contract's datastore

cbf (Tue, 22 May 2018 18:22:43 GMT):
https://github.com/bokkypoobah/Tokens#fixed-supply-token

cbf (Tue, 22 May 2018 19:02:03 GMT):
actually, I tried that one in remix and it has compile errors...

cbf (Tue, 22 May 2018 19:02:22 GMT):
still poking around for some samples we can use for testing

swetha (Tue, 22 May 2018 19:29:06 GMT):
We also learned at consensus that Ethereum is looking into combining EOAs and Contract Accounts so that there is only one type of account. Still searching for the actual proposal to see how that would affect us

cbf (Tue, 22 May 2018 19:38:47 GMT):
interesting

cbf (Tue, 22 May 2018 19:39:03 GMT):
I'm still trying to sort out where the eoa information is hosted

swetha (Tue, 22 May 2018 22:08:47 GMT):
the refactor has made it in release 0.18.0 of burrow :)

cbf (Wed, 23 May 2018 10:44:05 GMT):
yay

cbf (Thu, 24 May 2018 00:51:00 GMT):
https://github.com/christo4ferris/fixedtoken

cbf (Thu, 24 May 2018 00:51:19 GMT):
I deployed a simple fixed supply erc20 contract

cbf (Thu, 24 May 2018 00:51:46 GMT):
going to develop some tests to interact with it

cbf (Thu, 24 May 2018 00:52:27 GMT):
cbf$ node getAddr.js Address: 44a5026393f2eab185922d69971e1398ae9bd424 Name: Example Fixed Supply Token Owner: 0x613ac660a26a66a52eadc02cda9f6c7e7326e675 Balance: 1,000,000 Symbol: FIXED

cbf (Thu, 24 May 2018 01:20:25 GMT):
ok, will need to understand why I can query the balance but not transfer

guoger (Thu, 24 May 2018 02:24:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=fs38s7g4dvHRHK4mg) @cbf because we don't support it yet :( the `value` arg is hardcoded 0 when we call burrow evm. main reason is because we didn't implement `balance` api of account, mostly because we don't have account.

cbf (Thu, 24 May 2018 02:26:54 GMT):
hmmm

cbf (Thu, 24 May 2018 02:27:18 GMT):
the contract manages state

cbf (Thu, 24 May 2018 02:27:39 GMT):
this isn’t ether

cbf (Thu, 24 May 2018 02:27:46 GMT):
it is a token

guoger (Thu, 24 May 2018 02:32:09 GMT):
every time evmscc is invoked, we instantiate a brand new `callerAccount` using creator's public address, that is EOA data is not persisted

guoger (Thu, 24 May 2018 02:33:03 GMT):
i guess we could actually have a quick prototype to persist it into ledger, so we load the data from ledger to create `callerAcct`

cbf (Thu, 24 May 2018 02:33:15 GMT):
I am not using eoa data

guoger (Thu, 24 May 2018 02:33:24 GMT):
`balance` is part of eoa data

guoger (Thu, 24 May 2018 02:33:53 GMT):
``` type ConcreteAccount struct { Address Address PublicKey PublicKey Sequence uint64 Balance uint64 Code Bytecode StorageRoot []byte Permissions ptypes.AccountPermissions } ```

guoger (Thu, 24 May 2018 02:34:10 GMT):
here's what an account in burrow would contain

cbf (Thu, 24 May 2018 02:34:33 GMT):
will need to explore this more but that balance is ether if i understand

guoger (Thu, 24 May 2018 02:34:39 GMT):
yes

cbf (Thu, 24 May 2018 02:34:48 GMT):
nothing to do with my contract

guoger (Thu, 24 May 2018 02:35:08 GMT):
oh... you are creating erc20 token

cbf (Thu, 24 May 2018 02:35:13 GMT):
yes

guoger (Thu, 24 May 2018 02:35:14 GMT):
sorry, I misunderstood

guoger (Thu, 24 May 2018 02:36:30 GMT):
what error did you get?

cbf (Thu, 24 May 2018 02:49:11 GMT):
none... like I said, I need to look closer

cbf (Thu, 24 May 2018 02:49:31 GMT):
just that the orig balance is unchanged

cbf (Thu, 24 May 2018 11:15:37 GMT):
ah, interesting... so, the tokens are transferring to the other account but the contract does not seem to be deducting them from the contract balance

cbf (Thu, 24 May 2018 11:22:53 GMT):
I can successfully transfer balances to an account, and then from those accounts to/from eachother

cbf (Thu, 24 May 2018 11:22:53 GMT):
I can successfully transfer balances to an account, and then from those accounts to/from each other

cbf (Thu, 24 May 2018 13:03:03 GMT):
ok, just weird - redeployed and now managing the owner balance correctly

cbf (Thu, 24 May 2018 13:23:31 GMT):
ah, found what I messed up initially, the account of the owner is hard coded in the contract (sigh) and I didn't change originally... followed a different tutorial for essentially the same contract and set that correctly... now working as expected. What was weird is that it worked at all

guoger (Thu, 24 May 2018 14:10:32 GMT):
@cbf are you trying this https://github.com/christo4ferris/fixedtoken/blob/master/tok.sol

cbf (Thu, 24 May 2018 14:14:14 GMT):
yes, have it working now

cbf (Thu, 24 May 2018 14:14:42 GMT):
I pushed a new contract etc

cbf (Thu, 24 May 2018 14:15:14 GMT):
@guoger ^^

cbf (Thu, 24 May 2018 14:15:36 GMT):
you can play around with getBalance.js with the deployed contract

cbf (Thu, 24 May 2018 14:16:15 GMT):
btw, have we pulled in the latest from burrow master (v0.18) for the plugin?

guoger (Thu, 24 May 2018 14:20:49 GMT):
not yet, it's using develop. I'm making the change now

cbf (Thu, 24 May 2018 14:34:37 GMT):
can you please add tasks (not subtasks) to the epic for the remaining steps... I would include any system and functional testing we need to add to test the plugin itself

cbf (Thu, 24 May 2018 14:35:04 GMT):
we definitely want the plugin itself solid for 1.2 (end of june)

cbf (Thu, 24 May 2018 14:35:23 GMT):
@guoger @swetha

cbf (Thu, 24 May 2018 14:35:54 GMT):
as for the proxy, we should start work on a plan to harden and get the code into hyerledger

cbf (Thu, 24 May 2018 14:35:54 GMT):
as for the proxy, we should start work on a plan to harden and get the code into hyperledger

swetha (Thu, 24 May 2018 14:58:42 GMT):
As for the proxy, I am working on updating the proxy: https://github.com/swetharepakula/fabric-chaincode-evm/tree/update-proxy.

swetha (Thu, 24 May 2018 14:59:01 GMT):
I will take a look at what else we need for the plugin

cbf (Thu, 24 May 2018 15:26:26 GMT):
so we need to focus on the plugin for now

cbf (Thu, 24 May 2018 15:27:24 GMT):
I was looking at leveraging the fabric/integration "framework" (ginkgo) for testing the plugin

cbf (Thu, 24 May 2018 15:27:39 GMT):
but I also was not keen on a bunch of cut and paste

cbf (Thu, 24 May 2018 15:43:08 GMT):
@guoger digging deeper, I see that the plugin is still using a 1.1 base fabric

guoger (Thu, 24 May 2018 15:52:08 GMT):
i noticed that pluggable plugin is finished this week... will look into that

cbf (Thu, 24 May 2018 15:53:03 GMT):
yes

cbf (Thu, 24 May 2018 15:53:15 GMT):
so we need to strip out redundant packages

cbf (Thu, 24 May 2018 15:53:34 GMT):
where possible

cbf (Thu, 24 May 2018 15:54:27 GMT):
thinking logging

cbf (Thu, 24 May 2018 16:00:10 GMT):
in fact, the only logging is debug and that can be removed

cbf (Thu, 24 May 2018 16:00:24 GMT):
reducing the need to import flogging

cbf (Thu, 24 May 2018 16:03:44 GMT):
that leaves the shim package and protos... protos are likely fine... as is the shim I think

cbf (Thu, 24 May 2018 17:31:43 GMT):
I'm thinking that instead of e2e_cli we could do a derivative of fabric/integration with a simple use case of one peer, solo orderer, proxy (when we merge something) and drive some transactions through a series of contracts as a test environment

swetha (Thu, 24 May 2018 18:11:13 GMT):
When you say leveraging ginkgo do you mean for the integration tests? The plugin is already using ginkgo

cbf (Thu, 24 May 2018 18:31:56 GMT):
yes, but the integration tests go further and deploy a couple peers, orderer etc without needing to build containers etc

cbf (Thu, 24 May 2018 18:44:27 GMT):
so it might be a ligter-weight e2e test

cbf (Thu, 24 May 2018 18:44:27 GMT):
so it might be a lighter-weight e2e test

cbf (Thu, 24 May 2018 18:46:28 GMT):
also, I think we have over-complicated the build

cbf (Thu, 24 May 2018 18:47:14 GMT):
we just need to compile the plugin, we don't (to my knowledge) need to build in a fabric environment

cbf (Thu, 24 May 2018 18:51:04 GMT):
eg I just manually compiled and then ran e2e

swetha (Thu, 24 May 2018 19:04:11 GMT):
Oh that is interesting. We had an issue that if we didn't build it in the fabric environment because of the static referencing we would have a problem with the shared libraries

swetha (Thu, 24 May 2018 19:05:23 GMT):
And in terms of removing dependencies, we are using the msp package is pulling in a lot of pieces of fabric, including logging,

swetha (Thu, 24 May 2018 20:12:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=6TXcEwJPq9oqy6SfE) @cbf Are these the tests? https://github.com/hyperledger/fabric/tree/master/integration

cbf (Thu, 24 May 2018 20:35:01 GMT):
yes

cbf (Thu, 24 May 2018 20:38:33 GMT):
@swetha can you please add SPDX header to Gopkg.toml in your CR

cbf (Thu, 24 May 2018 20:38:42 GMT):
not passing checks

swetha (Thu, 24 May 2018 20:40:20 GMT):
Adding it

swetha (Thu, 24 May 2018 20:41:48 GMT):
Added another patch with the SPDX header

cbf (Thu, 24 May 2018 20:43:26 GMT):
thx

cbf (Thu, 24 May 2018 20:45:49 GMT):
@swetha https://gerrit.hyperledger.org/r/c/22309/

jtclark (Thu, 24 May 2018 20:52:18 GMT):
Has left the channel.

cbf (Thu, 24 May 2018 21:02:34 GMT):
I've got the logging

swetha (Thu, 24 May 2018 21:06:05 GMT):
I am looking into the integration tests. I will create a task for that oo

cbf (Thu, 24 May 2018 21:12:05 GMT):
think I'll create a sample app out of the simple contract

guoger (Fri, 25 May 2018 03:06:47 GMT):
looking at https://gerrit.hyperledger.org/r/#/c/22311/1, how do we do logging for `evmscc` then?

guoger (Fri, 25 May 2018 03:07:43 GMT):
i was thinking to have `evmscc` emit logs under name `evmscc`, and `evm` should be under `evmscc/evm`

guoger (Fri, 25 May 2018 03:08:07 GMT):
(`evm` logs are super verbose)

guoger (Fri, 25 May 2018 03:26:28 GMT):
also, why don't we have `hyperledger/fabric-baseimage:x86_64-0.4.8` in docker repo? I only see amd64, s390x and ppc64le...

cbf (Fri, 25 May 2018 09:52:51 GMT):
amd64 is the new x86_64

guoger (Fri, 25 May 2018 10:35:56 GMT):
right...

cbf (Fri, 25 May 2018 10:53:01 GMT):
https://jira.hyperledger.org/browse/FAB-10385

guoger (Fri, 25 May 2018 16:40:02 GMT):
@cbf reply https://gerrit.hyperledger.org/r/#/c/22311/ > those debug statements were not very useful, what logging do you think we need? I'm more inclined to keep the logger here cuz: - increase verbosity - evm logs can be redirected to it. it's currently no-op logger

cbf (Fri, 25 May 2018 16:42:48 GMT):
hmmm

cbf (Fri, 25 May 2018 16:43:52 GMT):
ok

cbf (Fri, 25 May 2018 19:59:04 GMT):
added a docker image build step and simplified the build

cbf (Fri, 25 May 2018 19:59:38 GMT):
also abandoned the logger CR

swetha (Fri, 25 May 2018 21:48:28 GMT):
I am taking a look at the simplified build process CR

cbf (Fri, 25 May 2018 23:20:58 GMT):
thx

swetha (Fri, 25 May 2018 23:46:52 GMT):
I am not able to build an image that works with the e2e example with the new dockerfile. Have not figured out what the error is quite yet. I am still digging into it

cbf (Sat, 26 May 2018 00:03:31 GMT):
hmmm...

guoger (Sat, 26 May 2018 01:23:17 GMT):
replied in CR

cbf (Sat, 26 May 2018 01:47:45 GMT):
well, the build part I messed up... but now is not loading plugin at all

cbf (Sat, 26 May 2018 01:48:50 GMT):
I have multi-stage build correctly building linux image

cbf (Sat, 26 May 2018 01:49:08 GMT):
but AFAICT the plugin logic is not being executed

cbf (Sat, 26 May 2018 01:54:11 GMT):
hmmm... I think that the latest tag is b0rking me;-)

guoger (Sat, 26 May 2018 02:00:48 GMT):
are you building plugin on your mac?

cbf (Sat, 26 May 2018 02:09:35 GMT):
oh ffs, there's a gotag needed in the peer build

cbf (Sat, 26 May 2018 02:09:51 GMT):
no in a multi-stage build

cbf (Sat, 26 May 2018 02:15:04 GMT):
got it

cbf (Sat, 26 May 2018 02:34:28 GMT):
well, almost

cbf (Sat, 26 May 2018 02:40:44 GMT):
sigh

cbf (Sat, 26 May 2018 02:49:51 GMT):
I'm going yo have to discuss with yacov

cbf (Sat, 26 May 2018 02:50:01 GMT):
it doesn't appear to be working correctly

cbf (Sat, 26 May 2018 02:50:24 GMT):
I had to compile the peer specially to add 'pluginsenabled' tag

cbf (Sat, 26 May 2018 02:50:41 GMT):
now it finds the plugin but panics immediately

cbf (Sat, 26 May 2018 03:03:59 GMT):
https://gist.github.com/christo4ferris/563090c5b673f364e646776b4ab28d1e

cbf (Sat, 26 May 2018 03:07:08 GMT):
I pushed another changeset with multistage build that I believe should work

cbf (Sat, 26 May 2018 03:07:45 GMT):
you also need to rebuild the fabric-peer image with GO_TAGS += pluginsenabled nopkcs11

cbf (Sat, 26 May 2018 03:08:06 GMT):
so that it enables the plugin feature and omits all the pkcs11 baggage

cbf (Sat, 26 May 2018 03:08:31 GMT):
I'm beat... will check with Yacov tomorrow

guoger (Sat, 26 May 2018 03:27:07 GMT):
`GO_TAGS=pluginsenabled EXPERIMENTAL=false DOCKER_DYNAMIC_LINK=true make peer-docker`

guoger (Sat, 26 May 2018 03:27:24 GMT):
this is how I build peer today, and we need to install `libltdl-dev` in peer

guoger (Sat, 26 May 2018 03:27:44 GMT):
so dockerfile for peer is also slightly modified

cbf (Sat, 26 May 2018 03:28:20 GMT):
I tried installing libtdl-dev when I built our image

cbf (Sat, 26 May 2018 03:28:30 GMT):
that resulted in a bigger mess

cbf (Sat, 26 May 2018 03:28:56 GMT):
DOCKER_DYNAMIC hmmm

guoger (Sat, 26 May 2018 03:29:47 GMT):
yea....

guoger (Sat, 26 May 2018 03:30:26 GMT):
and I suspect you'll hit another problem because you ought to build plugin *with* peer code, otherwise symbol resolution doesn't work. that's why we had this "weird" build process today

cbf (Sat, 26 May 2018 03:30:52 GMT):
symbol resolution should work

cbf (Sat, 26 May 2018 03:39:47 GMT):
interesting new stack trace

cbf (Sat, 26 May 2018 03:39:49 GMT):
goroutine 1 [running]: net/http.(*ServeMux).Handle(0x1d64f60, 0x7f7ca55921a2, 0xf, 0x1551100, 0x7f7ca5c711a8) /opt/go/src/net/http/server.go:2353 +0x243 net/http.(*ServeMux).HandleFunc(0x1d64f60, 0x7f7ca55921a2, 0xf, 0x7f7ca5c711a8) /opt/go/src/net/http/server.go:2368 +0x57 net/http.HandleFunc(0x7f7ca55921a2, 0xf, 0x7f7ca5c711a8) /opt/go/src/net/http/server.go:2380 +0x50 github.com/hyperledger/fabric-chaincode-evm/vendor/golang.org/x/net/trace.init.0() /opt/gopath/src/github.com/hyperledger/fabric-chaincode-evm/vendor/golang.org/x/net/trace/trace.go:115 +0x44 plugin.open(0xc42023c2e0, 0xf, 0xc420202b60, 0x0, 0x0) /opt/go/src/plugin/plugin_dlopen.go:113 +0xb21 plugin.Open(0xc42023c2e0, 0x12, 0x1569320, 0xc420202b60, 0x0) /opt/go/src/plugin/plugin.go:32 +0x35 github.com/hyperledger/fabric/core/scc.loadPlugin(0xc42023c2e0, 0x12, 0x0) /opt/gopath/src/github.com/hyperledger/fabric/core/scc/loadsysccs.go:70 +0x175 github.com/hyperledger/fabric/core/scc.loadSysCCsWithConfig(0xc4200b4370, 0x1, 0x1) /opt/gopath/src/github.com/hyperledger/fabric/core/scc/loadsysccs.go:51 +0xa6 github.com/hyperledger/fabric/core/scc.loadSysCCs.func1() /opt/gopath/src/github.com/hyperledger/fabric/core/scc/loadsysccs.go:44 +0x97 sync.(*Once).Do(0x1d83808, 0x14cc720) /opt/go/src/sync/once.go:44 +0xbe github.com/hyperledger/fabric/core/scc.loadSysCCs(0xc4204360a0, 0xc4200b4338, 0xc4204360a0, 0x154dd20) /opt/gopath/src/github.com/hyperledger/fabric/core/scc/loadsysccs.go:38 +0x39 github.com/hyperledger/fabric/core/scc.CreateSysCCs(0x15665a0, 0xc4200b4338, 0xc4204360a0, 0x154dd20, 0xc420487aa0, 0x263, 0x3c0, 0x0) /opt/gopath/src/github.com/hyperledger/fabric/core/scc/register_pluginsenabled.go:20 +0x98 github.com/hyperledger/fabric/peer/node.registerChaincodeSupport(0xc420180bd0, 0xc42003809b, 0x1b, 0x155f3a0, 0xc4200b4270, 0x154dd20, 0xc420487aa0, 0x0, 0x0, 0x12cdf20, ...) /opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:631 +0x5df github.com/hyperledger/fabric/peer/node.serve(0x1d83720, 0x0, 0x0, 0x0, 0x0) /opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:231 +0xaf8 github.com/hyperledger/fabric/peer/node.glob..func1(0x1c7ccc0, 0x1d83720, 0x0, 0x0, 0x0, 0x0) /opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:111 +0x9c github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x1c7ccc0, 0x1d83720, 0x0, 0x0, 0x1c7ccc0, 0x1d83720) /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:698 +0x46d github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x1c7d320, 0x1d65c30, 0xf, 0x2) /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:783 +0x2e4 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x1c7d320, 0x2, 0xffffffffffffffff) /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:736 +0x2b main.main() /opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:97 +0x5bf

cbf (Sat, 26 May 2018 03:40:37 GMT):
open calls init on all

cbf (Sat, 26 May 2018 03:41:59 GMT):
getting closer

cbf (Sat, 26 May 2018 03:43:12 GMT):
pushed another patchset

cbf (Sat, 26 May 2018 03:43:17 GMT):
heading to bed

guoger (Sat, 26 May 2018 03:44:48 GMT):
this is the symbol resolution thing...

guoger (Sat, 26 May 2018 03:45:18 GMT):
basically, plugin and peer rely on `net`, which should be loaded once

guoger (Sat, 26 May 2018 03:45:40 GMT):
although, they resolve to two different symbol, therefore this pkg is loaded twice

guoger (Sat, 26 May 2018 03:46:21 GMT):
they try to register to the same endpoint during `init`, resulting in panic for the second attempt

guoger (Sat, 26 May 2018 03:47:39 GMT):
do you see something like "endpoint already in use" before the stack?

cbf (Sat, 26 May 2018 03:54:24 GMT):
well this is a bug with pluggable then

cbf (Sat, 26 May 2018 03:55:03 GMT):
need to tease apart the shim dependencies

cbf (Sat, 26 May 2018 03:55:18 GMT):
they should be minimal

cbf (Sat, 26 May 2018 03:56:06 GMT):
literally, all we should need is the interface

guoger (Sat, 26 May 2018 04:17:09 GMT):
this is the discussion we had: https://chat.hyperledger.org/channel/fabric-orderer-dev?msg=pjqrayBr4TA5XHRs9

guoger (Sat, 26 May 2018 04:17:22 GMT):
so yes, it's a problem for all plugins

cbf (Sat, 26 May 2018 11:56:43 GMT):
sigh well, it might be easier to do the following

cbf (Sat, 26 May 2018 11:57:08 GMT):
clone fabric

cbf (Sat, 26 May 2018 11:58:05 GMT):
copy fabric-chaincode-evm/plugin into fabric repo

cbf (Sat, 26 May 2018 11:58:26 GMT):
copy fabric-chaincode-evm/statemanager into fabric repo

cbf (Sat, 26 May 2018 11:59:45 GMT):
sed the package path names

cbf (Sat, 26 May 2018 12:00:01 GMT):
run dep ensure to pick up missing dependencies

cbf (Sat, 26 May 2018 12:00:08 GMT):
build plugin

guoger (Sat, 26 May 2018 13:01:14 GMT):
that's essentially what `build.sh` does today. instead of copy statemanager to fabric repo, we are copying it to fabric/vendor, so we don't need to sed package path name

guoger (Sat, 26 May 2018 13:01:44 GMT):
but i would agree that making shim dependencies minimal is a better approach

guoger (Sat, 26 May 2018 13:03:39 GMT):
one more difference is that we are copying fabric to a temp folder, instead of cloning it. but i guess we ought to change it to clone a specific version of fabric

cbf (Sat, 26 May 2018 13:07:31 GMT):
I almost have it

cbf (Sat, 26 May 2018 13:07:45 GMT):
dealing with dep craziness

cbf (Sat, 26 May 2018 13:08:25 GMT):
although one could argue we could build fabric as we need it too

guoger (Sat, 26 May 2018 13:08:29 GMT):
yup, we stick with `govendor` instead of `dep`, because `dep` couldn't output what we wanted

cbf (Sat, 26 May 2018 13:08:54 GMT):
well dep is more precise

cbf (Sat, 26 May 2018 13:09:06 GMT):
which is both a curse and a blessing

cbf (Sat, 26 May 2018 13:11:42 GMT):
LMAO

cbf (Sat, 26 May 2018 13:11:46 GMT):
omg so close

cbf (Sat, 26 May 2018 13:12:12 GMT):
panic: Error opening plugin at path /opt/lib/evmscc.so: plugin.Open("/opt/lib/evmscc"): plugin was built with a different version of package github.com/hyperledger/fabric/idemix

cbf (Sat, 26 May 2018 13:15:29 GMT):
so yeah, I think building the peer binary in the same stage as we build the plugin will be best

cbf (Sat, 26 May 2018 13:19:16 GMT):
2018-05-26 13:21:25.589 UTC [sccapi] loadSysCCsWithConfig -> INFO 00e Successfully loaded SCC evmscc from path /opt/lib/evmscc.so

cbf (Sat, 26 May 2018 13:19:18 GMT):
YAY

cbf (Sat, 26 May 2018 13:19:25 GMT):
BUT, now escc missing

cbf (Sat, 26 May 2018 13:19:26 GMT):
weird

cbf (Sat, 26 May 2018 13:35:45 GMT):
BOOM!

cbf (Sat, 26 May 2018 14:03:15 GMT):
https://gerrit.hyperledger.org/r/22371

guoger (Mon, 28 May 2018 02:11:45 GMT):
do we have `fabric-buildenv` in docker hub?

guoger (Mon, 28 May 2018 02:11:51 GMT):
also, ``` Step 6/18 : RUN EXECUTABLES=go GO_TAGS=pluginsenabled EXPERIMENTAL=false DOCKER_DYNAMIC_LINK=true make peer ---> Running in 0a2a524f442e .build/bin/peer CGO_CFLAGS=" " GOBIN=/opt/gopath/src/github.com/hyperledger/fabric/.build/bin go install -tags "pluginsenabled" -ldflags "-X github.com/hyperledger/fabric/common/metadata.Version=1.2.0-snapshot-afdaeb3 -X github.com/hyperledger/fabric/common/metadata.BaseVersion=0.4.8 -X github.com/hyperledger/fabric/common/metadata.BaseDockerLabel=org.hyperledger.fabric -X github.com/hyperledger/fabric/common/metadata.DockerNamespace=hyperledger -X github.com/hyperledger/fabric/common/metadata.BaseDockerNamespace=hyperledger -X github.com/hyperledger/fabric/common/metadata.Experimental=false" github.com/hyperledger/fabric/peer # github.com/hyperledger/fabric/common/crypto/tlsgen common/crypto/tlsgen/key.go:36:20: undefined: x509.MarshalPKCS8PrivateKey # github.com/hyperledger/fabric/vendor/github.com/docker/docker/pkg/archive vendor/github.com/docker/docker/pkg/archive/archive.go:364:5: hdr.Format undefined (type *tar.Header has no field or method Format) vendor/github.com/docker/docker/pkg/archive/archive.go:364:15: undefined: tar.FormatPAX vendor/github.com/docker/docker/pkg/archive/archive.go:1166:7: hdr.Format undefined (type *tar.Header has no field or method Format) vendor/github.com/docker/docker/pkg/archive/archive.go:1166:17: undefined: tar.FormatPAX Makefile:256: recipe for target '.build/bin/peer' failed make: *** [.build/bin/peer] Error 2 The command '/bin/sh -c EXECUTABLES=go GO_TAGS=pluginsenabled EXPERIMENTAL=false DOCKER_DYNAMIC_LINK=true make peer' returned a non-zero code: 2 make: *** [docker] Error 2 ```

guoger (Mon, 28 May 2018 09:17:03 GMT):
@cbf commented on your CR. I propose following changes based on it: https://github.com/guoger/fabric-chaincode-evm/commit/6e08048ee64a00d7eb2e8891b78e807c29407f84

guoger (Mon, 28 May 2018 09:17:18 GMT):
verified locally

guoger (Mon, 28 May 2018 09:49:45 GMT):
except that `buildenv` image is built locally...

cbf (Mon, 28 May 2018 10:47:57 GMT):
yes, buildenv is local only... we could publish I suppose

cbf (Mon, 28 May 2018 10:48:47 GMT):
as for DEBUG v INFO, would be better IMO to set DEBUG locally for checkOSN... the debug in the logs is worthless noise

cbf (Mon, 28 May 2018 18:27:58 GMT):
@guoger pushed another patchset addressing your comments

cbf (Mon, 28 May 2018 18:28:41 GMT):
once we get to 1.2, we can pull the dependent images and will be much less kludgy

cbf (Mon, 28 May 2018 18:29:03 GMT):
I'll work with ramesh to get the buildenv published - even if only to nexus

guoger (Tue, 29 May 2018 02:35:07 GMT):
@cbf I'm more inclined to keep `evmscc-linux` target, because: - we still have the option to load `evmscc.so` into a locally built peer, for dev purpose. (building the whole fabric-peer-evm is just too expensive) - you don't need to hardcode missing pkgs in Dockerfile (sed scripting), and you don't need to build evmscc there at all. you could simply make `evmscc-linux` a dependency for `docker`, as I proposed in my example commit

cbf (Tue, 29 May 2018 11:30:38 GMT):
ok, now I am confused

cbf (Tue, 29 May 2018 11:30:47 GMT):
evmscc-linux is not needed for docker

cbf (Tue, 29 May 2018 11:31:21 GMT):
I can add evmscc-linux to make a linux .so but the dependencies will be wrong

cbf (Tue, 29 May 2018 11:31:21 GMT):
I can add evmscc-linux to make a linux .so but the vendored dependencies will be wrong

cbf (Tue, 29 May 2018 11:33:34 GMT):
I can change GOOS so that it can be overridden by setting the env var

cbf (Tue, 29 May 2018 11:34:00 GMT):
but it won't work

cbf (Tue, 29 May 2018 11:34:13 GMT):
I was sorely tempted to just remove this

cbf (Tue, 29 May 2018 11:39:49 GMT):
the problem we have, actually, is that the whole concept of plugin scc is flawed given the dependencies we need to pull in

cbf (Tue, 29 May 2018 11:57:22 GMT):
we cannot be expecting developers of SCC plugins to have to jump through these hoops

cbf (Tue, 29 May 2018 11:57:42 GMT):
it's just insane

silasdavis (Tue, 29 May 2018 12:45:09 GMT):
Hi guys, great to see you are on Burrow 0.18.0.... Was just looking over code, can someone explain this line: https://github.com/hyperledger/fabric-chaincode-evm/blob/master/plugin/evmscc.go#L87

silasdavis (Tue, 29 May 2018 12:45:42 GMT):
Looks like the zero value is being used to signal deploy

silasdavis (Tue, 29 May 2018 12:46:06 GMT):
we use `(*Address)(nil)` for this

silasdavis (Tue, 29 May 2018 12:46:31 GMT):
one reason is that `ZeroAddress` is actually used for the global permission account address (dubiously perhaps)

silasdavis (Tue, 29 May 2018 12:46:52 GMT):
having said this, it's probably unambiguous in practice

cbf (Tue, 29 May 2018 13:20:42 GMT):
thanks!

guoger (Tue, 29 May 2018 14:03:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=P6534BeY2tr46v8tD) @cbf we can make it as a dependency for docker, to get rid of sed scripting, cuz hardcoding missing pkgs is just hard to maintain... (obviously we will eventually get rid of it till shim pkgs are torn apart.)

guoger (Tue, 29 May 2018 14:04:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=CNY8dTLYPKeq4RHiZ) @cbf linux .so is also built within Fabric, so dependencies path are actually correct, which can be used by `make docker`, I've tested this: https://github.com/guoger/fabric-chaincode-evm/commit/6e08048ee64a00d7eb2e8891b78e807c29407f84

guoger (Tue, 29 May 2018 14:05:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=DZaEm6yyb9i3xKZN2) @cbf agreed

cbf (Tue, 29 May 2018 18:14:40 GMT):
please take a look at the latest patchset... once the base is built, you can build a new plugin in just over a minute, and in ~45 secs once we get libltdl-dev added to baseimage

cbf (Tue, 29 May 2018 18:15:25 GMT):
note that what I am trying to accomplish here is slightly broader than just this plugin

cbf (Tue, 29 May 2018 18:16:11 GMT):
because frankly, the whole concept of scc plugin is flawed given the mess with vendored dependencies

swetha (Tue, 29 May 2018 19:23:10 GMT):
@cbf: Left a comment on gerrit. I think if we should remove the `make evmscc` because the plugin that created that way can't be used. But I do prefer what Jay suggested with make docker depend on the evmscc build.

swetha (Tue, 29 May 2018 19:23:10 GMT):
@cbf: Left a comment on gerrit. I think we should remove the `make evmscc` because the plugin that created that way can't be used. But I do prefer what Jay suggested with make docker depend on the evmscc build.

swetha (Tue, 29 May 2018 19:24:03 GMT):
I agree, scc plugin logic quite flawed right now. I think in the docs for plugin vscc or escc they explicitly state don't use packages from fabric for the same reason

swetha (Tue, 29 May 2018 19:24:22 GMT):
Some of those problems are also because of how plugins work in Go

cbf (Tue, 29 May 2018 19:24:28 GMT):
right but they do not require the shim

cbf (Tue, 29 May 2018 19:25:38 GMT):
@swetha but the evmscc build step needs the whole convoluted copy-paste net the delta blah blah

swetha (Tue, 29 May 2018 19:26:52 GMT):
I rather just remove the option then and we give directions to people on how to extract the `evmscc.so` from the docker image

swetha (Tue, 29 May 2018 19:27:38 GMT):
Or actually that is could be what make evmscc does and it will depend on docker

swetha (Tue, 29 May 2018 19:27:38 GMT):
Or actually that is could be what `make evmscc` does and it will depend on docker

swetha (Tue, 29 May 2018 19:27:38 GMT):
Or actually that could be what `make evmscc` does and it will depend on docker

cbf (Tue, 29 May 2018 19:27:55 GMT):
it's also going to leave a bunch of orphaned directories in /tmp every time the build fails

swetha (Tue, 29 May 2018 19:28:36 GMT):
That is true, I don't like that either

cbf (Tue, 29 May 2018 19:29:11 GMT):
I think that the multi-stage is cleaner

cbf (Tue, 29 May 2018 19:30:11 GMT):
and what I am hoping will fall out of this is a simple pattern that I can make generic for plugins

swetha (Tue, 29 May 2018 19:31:02 GMT):
I agree with that idea, but the only concern is that we have no way to extract the plugin itself.

cbf (Tue, 29 May 2018 19:31:30 GMT):
actually, that isn't quite tru

cbf (Tue, 29 May 2018 19:31:30 GMT):
actually, that isn't quite true

swetha (Tue, 29 May 2018 19:32:02 GMT):
We could pull it out of the docker image

cbf (Tue, 29 May 2018 19:32:49 GMT):
you can reference an image in the COPY from=hyperledger/fabric-peer-evm:latest /opt/lib/evmscc.so to a mounted fs

swetha (Tue, 29 May 2018 19:34:04 GMT):
Yea I was thinking we do that instead of running go build for `make evmscc`? Or we give directions in a Readme and remove that option in the Makefile

cbf (Tue, 29 May 2018 19:34:44 GMT):
thinking

swetha (Tue, 29 May 2018 19:39:49 GMT):
Something similar to these lines: https://github.com/cloudfoundry/diego-release/blob/develop/scripts/get-envoy-binary-from-docker-image.sh#L2-L3

cbf (Tue, 29 May 2018 19:40:44 GMT):
actually, you cannot mount volume in build, but you can run the image and copy the file to a mounted volume

swetha (Tue, 29 May 2018 19:42:08 GMT):
Yup you can do something similar to what I linked above

cbf (Tue, 29 May 2018 20:25:01 GMT):
yeah that works... incoming patchset thanks

cbf (Tue, 29 May 2018 22:00:06 GMT):
ok, think this is pretty tight now... make evmscc-linux will build the lot and extract the .so to .build/linux/lib

cbf (Tue, 29 May 2018 22:00:47 GMT):
if you JUST change the .go source files (not tests) then it will just build 'docker' target and extract

cbf (Tue, 29 May 2018 22:02:15 GMT):
once I get libltdl-dev into baseimage, then the normal build will be only ~45 secs... only slightly over 1m now

cbf (Tue, 29 May 2018 22:09:40 GMT):
@swetha did you validate the build locally? I have a bunch of times and different combinatorial states (make clean, remove .so, modify Gopkg.toml and any .go) and seems clean

swetha (Tue, 29 May 2018 22:10:25 GMT):
oh everytime i built i had no issues

swetha (Tue, 29 May 2018 22:10:56 GMT):
I did remove previously built docker images before i would run `make docker`

swetha (Tue, 29 May 2018 22:10:56 GMT):
I did remove previously built docker images before i ran `make docker`

cbf (Tue, 29 May 2018 22:11:32 GMT):
cool thx

swetha (Tue, 29 May 2018 22:12:13 GMT):
I am validating again just to verify

swetha (Tue, 29 May 2018 22:20:47 GMT):
@cbf, i missed the integration-test change. We need `./` to prefix the network_setup script

cbf (Tue, 29 May 2018 22:29:42 GMT):
ah, thanks... my path defaults to allow that... fixing

cbf (Tue, 29 May 2018 22:31:51 GMT):
good catch thanks... new ps

swetha (Tue, 29 May 2018 23:17:08 GMT):
@cbf: I am running into an error running the integration-test because `network_setup down` destroys the images needed for `network_setup up` needs. Are you having the same issue?

cbf (Tue, 29 May 2018 23:46:28 GMT):
I'm not seeing that

cbf (Tue, 29 May 2018 23:47:35 GMT):
oh interesting...

cbf (Tue, 29 May 2018 23:47:52 GMT):
it is deleting the peer-evm-base image

cbf (Tue, 29 May 2018 23:48:27 GMT):
I see the problem

cbf (Wed, 30 May 2018 00:00:45 GMT):
fixed

swetha (Wed, 30 May 2018 00:00:47 GMT):
I am trying to figure out what is the best way to achieve the same result

swetha (Wed, 30 May 2018 00:00:56 GMT):
oh nvm

cbf (Wed, 30 May 2018 00:11:57 GMT):
well, the removeUnwantedImages is purging more than it really should

cbf (Wed, 30 May 2018 00:12:11 GMT):
and is not being specific enough

swetha (Wed, 30 May 2018 00:23:10 GMT):
+2 the CR, everything works locally

swetha (Wed, 30 May 2018 00:23:10 GMT):
+2ed the CR, everything works locally

nhrishi (Wed, 30 May 2018 01:26:44 GMT):
Has joined the channel.

bur (Wed, 30 May 2018 10:59:34 GMT):
Has joined the channel.

cbf (Wed, 30 May 2018 13:33:55 GMT):
addressed @guoger comments - clean up dross and add core.yaml as dependency

jwaup (Wed, 30 May 2018 13:56:49 GMT):
Has joined the channel.

guoger (Wed, 30 May 2018 14:24:08 GMT):
you probably missed this? https://gerrit.hyperledger.org/r/#/c/22371/10/Dockerfile.base@22

cbf (Wed, 30 May 2018 15:32:32 GMT):
@guoger I answered in a draft comment and never submitted. Here was my response: correct, but I am trying to establish a baseline... the second ensure takes only a few seconds because nothing to be done. I don't want to move this to the Dockerfile.

cbf (Wed, 30 May 2018 15:42:51 GMT):
I just pushed another patchset... I was readying a CR for baseimage to add libltdl-dev but in doing so, realized that we don't seem to need it. I just tested w/o and things look good here

swetha (Wed, 30 May 2018 17:18:32 GMT):
It worked for me locally without the library as well. That is very interesting

cbf (Wed, 30 May 2018 18:05:08 GMT):
I don't recall the issue that it was supposed to be fixing... but possibly the dependencies that caused it have been fixed?

guoger (Thu, 31 May 2018 02:02:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=8WgQX422KiJd6sAiu) @cbf it's pretty hard to solve though... `golang.org/x/net` is dependency of `grpc` and `tendermint`... tearing apart shim interface does not help

guoger (Thu, 31 May 2018 03:03:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=MSozHiMPrmvAw3yHw) @cbf so the issue was go requires it to load plugin... but yeah, it got fixed somehow.. i recall it has something to do with pkcs, and probably fixed in `e91df49c8ad05ec5a9c9dce75e87cc29549aa690` of fabric.. not sure

guoger (Thu, 31 May 2018 05:49:40 GMT):

dep.png

compleatang (Thu, 31 May 2018 08:53:01 GMT):
FWIW, our (burrow's) part of that graph should simplify considerably in 0.18.1 with the migration to using go-crypto nearly exclusively.

cbf (Thu, 31 May 2018 11:43:22 GMT):
@guoger can you please do another review? https://gerrit.hyperledger.org/r/c/22371/

cbf (Thu, 31 May 2018 14:14:56 GMT):
@swetha the contract in evmscc_test.go doesn't have a license AFAICT

cbf (Thu, 31 May 2018 14:15:24 GMT):
I think that we need to use and reference one that does (have an MIT or Apache license)

cbf (Thu, 31 May 2018 14:22:35 GMT):
while the voting app is simple maybe an ERC20 token dapp? https://github.com/christo4ferris/fixedtoken/blob/master/tok.sol

cbf (Thu, 31 May 2018 14:22:52 GMT):
I couldn't find the voting app with a license

cbf (Thu, 31 May 2018 14:23:09 GMT):
and the ethereum docs don't seem to have a license - just a copyright

swetha (Thu, 31 May 2018 16:34:20 GMT):
Okay I will start digging for that

cbf (Thu, 31 May 2018 17:16:58 GMT):
besides, I think having an ERC20 token contract in the tests will be a good signal

cbf (Thu, 31 May 2018 17:17:19 GMT):
we can leverage it to also test account support when we get there

swetha (Thu, 31 May 2018 17:32:34 GMT):
I like that idea. For the simpler tests we I found this: https://github.com/katopz/truffle-simple-storage-example/blob/master/contracts/SimpleStorage.sol

swetha (Thu, 31 May 2018 17:33:13 GMT):
But it is the exact same contract as what is on the Solidity documentation but the variables names are changed and then it was committed under the MIT license. I assume we can do the same thing?

swetha (Thu, 31 May 2018 17:57:55 GMT):
@cbf: https://github.com/christo4ferris/fixedtoken/blob/master/tok.sol#L120 that has an extra 2 at the end of the address

cbf (Thu, 31 May 2018 17:59:25 GMT):
yes, MIT is fine

cbf (Thu, 31 May 2018 18:00:29 GMT):
thanks, I'll fix... must hav ebeen a typo

cbf (Thu, 31 May 2018 18:12:37 GMT):
fixed thanks

swetha (Thu, 31 May 2018 18:47:27 GMT):
docker.base

guoger (Thu, 31 May 2018 18:50:51 GMT):
everything looks good and works locally! but i'm still struggling to understand why we duplicate evmscc pkg setup in `Dockerfile.base`? @cbf

guoger (Thu, 31 May 2018 18:52:37 GMT):
also, probably you could kill this comment in `Dockerfile`? > # TODO modify baseimage to include this

guoger (Thu, 31 May 2018 18:52:49 GMT):
since we are not installing libltdl anymore

guoger (Thu, 31 May 2018 19:01:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=LFW3uhkHPm9oJw5ZN) @compleatang awesome! looking forward to that!

cbf (Thu, 31 May 2018 19:12:16 GMT):
the duplication is as follows... I am building a baseline image that has peer with plugins enabled and the merged vendor content

cbf (Thu, 31 May 2018 19:12:58 GMT):
then the Dockerfile starts FROM that image and only needs to run dep ensure for any package changes in the plugin code

cbf (Thu, 31 May 2018 19:13:05 GMT):
much shorter

cbf (Thu, 31 May 2018 19:13:19 GMT):
the first dep ensure takes like 5 minutes

cbf (Thu, 31 May 2018 19:13:32 GMT):
the Dockerfile build takes < minute

guoger (Thu, 31 May 2018 19:14:53 GMT):
oh, now i get it

cbf (Thu, 31 May 2018 19:15:57 GMT):
incoming patchset 14

guoger (Thu, 31 May 2018 19:16:21 GMT):
do you mind adding some comments explaining this while you push patch 14?

cbf (Thu, 31 May 2018 19:16:46 GMT):
sure

guoger (Thu, 31 May 2018 19:17:01 GMT):
just for posterity

guoger (Thu, 31 May 2018 19:24:19 GMT):
also, just thinking of the process of building evmscc against modified fabric...

guoger (Thu, 31 May 2018 19:25:06 GMT):
like if i make some changes in fabric, and wanna see if evmscc could work with it..

guoger (Thu, 31 May 2018 19:25:42 GMT):
but let's get your patch in and fix it later

cbf (Thu, 31 May 2018 19:31:48 GMT):
could add a step that checks the sha, but I think that the simplest thing is to make clean evmscc-linux

guoger (Thu, 31 May 2018 19:33:29 GMT):
i meant that evmscc is built against a freshly cloned fabric, instead of my local changes

guoger (Thu, 31 May 2018 19:42:22 GMT):
gonna sleep now, i'll give +2 tomorrow to your patch 15. sorry I've been a bit picky on this...

cbf (Thu, 31 May 2018 19:54:58 GMT):
no worries, keeping me honest patchset 15 submitted - also fixed issue when you run make integration-test with some stopped containers from a previous test

cbf (Fri, 01 Jun 2018 18:52:35 GMT):
one last patchset to align with v0.18.0 burrow... I had mistakenly picked a constraint from a stale master

cbf (Fri, 01 Jun 2018 18:52:58 GMT):
https://gerrit.hyperledger.org/r/c/22371/

swetha (Fri, 01 Jun 2018 20:41:10 GMT):
Cool, reviewed the new patch. looks good to go

cbf (Sat, 02 Jun 2018 11:40:14 GMT):
thanks

cbf (Sat, 02 Jun 2018 11:42:40 GMT):
now we need to test... how is the integration test "framework" coming?... it would be good if we had the ability to drop in different contracts to test to create a suite

cbf (Sat, 02 Jun 2018 11:43:04 GMT):
I'm working on getting Caliper working

cbf (Sat, 02 Jun 2018 11:43:42 GMT):
trouble is Caliper is a disaster... docs don't match the code, code is a bit tangled and doesn't work with 1.2 quite yet

guoger (Sun, 03 Jun 2018 03:22:57 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=6xeMNWttGnaBGPrHQ) @swetha which is it?

swetha (Mon, 04 Jun 2018 02:49:15 GMT):
@cbf, so I haven't been able to get the plugin to run. I am still trying to figure out why that is. The other issue I realized Friday was that I wasn't compiling the plugin within fabric which might cause a problem .

swetha (Mon, 04 Jun 2018 02:49:24 GMT):
@guoger, I reviewed patch 15

cbf (Mon, 04 Jun 2018 11:12:55 GMT):
@swetha are you trying to get it running on the deployed Fabric instance for the demo? Are you using the image generated by the build for Fabric?

swetha (Mon, 04 Jun 2018 17:42:04 GMT):
@cbf, The integration doesn't use an image. It runs the peer locally. Images are only used for kafka and for ccenv

cbf (Mon, 04 Jun 2018 20:30:41 GMT):
ah, right... context matters;-)

cbf (Mon, 04 Jun 2018 20:30:48 GMT):
we need a native build for that

cbf (Mon, 04 Jun 2018 20:31:00 GMT):
that will be a bit more challenging, I think

cbf (Mon, 04 Jun 2018 20:31:28 GMT):
first, we need a build of peer that has pkcs11 off.

cbf (Mon, 04 Jun 2018 20:32:44 GMT):
you cannot pull the plugin out of the image to run on a mac, needs to be built natively.

cbf (Tue, 05 Jun 2018 21:36:18 GMT):
sorry, been MIA today... had to put my dog down - cancer sucks...

cbf (Tue, 05 Jun 2018 21:37:16 GMT):
so, I think that in order to build native, we will need to bring back the rsync process from before

swetha (Tue, 05 Jun 2018 22:05:55 GMT):
@cbf, Sorry to hear that

swetha (Tue, 05 Jun 2018 22:06:24 GMT):
Yup I redoing some of the build process and making it in go

swetha (Tue, 05 Jun 2018 22:07:05 GMT):
build process that I was initially taking from the fabric/integration tests

cbf (Tue, 05 Jun 2018 22:43:10 GMT):
it's still a mess

cbf (Tue, 05 Jun 2018 22:43:16 GMT):
sigh

cbf (Tue, 05 Jun 2018 22:43:26 GMT):
I was trying myself to build native

cbf (Tue, 05 Jun 2018 22:43:34 GMT):
failing miserably

cbf (Tue, 05 Jun 2018 22:44:41 GMT):
tendermint guys mucking with their libs

cbf (Tue, 05 Jun 2018 22:50:27 GMT):
I am just not thinking well today... because nothing makes sense

swetha (Tue, 05 Jun 2018 23:00:58 GMT):
I am thinking it might be better have the plugin and peer built outside of the integration test itself

guoger (Wed, 06 Jun 2018 05:25:13 GMT):
@swetha just thinking more of it, we could actually load evmscc as *user chaincode* for integration test, so we don't need to deal with messy build. and when people use it, it's still loaded as system chaincode

guoger (Wed, 06 Jun 2018 06:12:40 GMT):
just tried and it works!

guoger (Wed, 06 Jun 2018 06:13:07 GMT):
we just need to add a meaningful `main` to evmscc, which is not ran as plugin anyway

guoger (Wed, 06 Jun 2018 06:13:07 GMT):
we just need to add a meaningful `main` to evmscc, which is not ran if loaded as plugin anyway

guoger (Wed, 06 Jun 2018 06:15:27 GMT):
so i think it significantly simplifies the integration test. we just need to copy/clone fabric repo to tmp dir and compile there, which I think you've been doing already

guoger (Wed, 06 Jun 2018 06:15:27 GMT):
so i think it significantly simplifies the integration test as you don't need to deal with plugin build *at all*. we just need to copy/clone fabric repo to tmp dir and compile there, which I think you've been doing already

guoger (Wed, 06 Jun 2018 06:17:11 GMT):
i'll leave that part to you and I'll be working on modifying integration test so we could easily add new contracts, so I don't step on your toes

compleatang (Wed, 06 Jun 2018 08:21:00 GMT):
@cbf sorry to hear about your dog passing. Out of curiosity which tendermint libs were problematic for y'all? They mess with those a lot and we're keen to isolate our downstream to the extent we can...

guoger (Wed, 06 Jun 2018 09:53:48 GMT):
@compleatang hi, thank you so much for helping us out! [ ](https://chat.hyperledger.org/channel/fabric-evm?msg=qce3sQBw5rBJfK8rs) by looking at this graph, both projects ultimately depend on `x/net/trace`. When we load burrow-evm as a plugin, `init` in `trace` is called for the second time, which triggers a panic because the `/debug/requests` endpoint is registered already.

guoger (Wed, 06 Jun 2018 09:54:06 GMT):
@cbf sorry for your loss....

guoger (Wed, 06 Jun 2018 09:58:26 GMT):
@compleatang so I think it's a problem with grpc, instead of tendermint. (possibly `go-kit/kit` as well)

cbf (Wed, 06 Jun 2018 13:17:03 GMT):
@compleatang go-wire which seems to have been renamed go-amino

swetha (Wed, 06 Jun 2018 16:06:14 GMT):
@guoger, did you have to run a `dep ensure` or something? Not all of the plugin dependencies are vendored in Fabric

guoger (Wed, 06 Jun 2018 17:12:52 GMT):
no, running evm in user chaincode simply builds it as separate binary, therefore not requiring any deps in fabric

guoger (Wed, 06 Jun 2018 17:16:09 GMT):
just trying to demo the idea: https://github.com/guoger/fabric/commit/9e5c37ffce4c8370bb81c2a238537e0182a2d856

guoger (Wed, 06 Jun 2018 17:16:33 GMT):
and you need to put this to evm plugin main function: ``` func main() { err := shim.Start(&EvmChaincode{}) if err != nil { fmt.Fprintf(os.Stderr, "Exiting EVM chaincode: %s", err) os.Exit(2) } } ```

compleatang (Wed, 06 Jun 2018 17:46:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=uSbLhxFqumtCsDJ57) @cbf thanks. That one we couldn't totally insulate but we're ripping out a bunch of other stuff related to their serialization...

compleatang (Wed, 06 Jun 2018 17:48:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=yx8xLKoLFGMTFbYQi) @guoger do you mean burrow and fabric or burrow and tendermint. We may be able to move the init a level higher in our stack. Cc @seanyoung

seanyoung (Wed, 06 Jun 2018 17:48:10 GMT):
Has joined the channel.

compleatang (Wed, 06 Jun 2018 17:48:41 GMT):
If it was possible for you to dump an issue in burrows repo that would be very helpful.

swetha (Wed, 06 Jun 2018 18:21:43 GMT):
@guoger: Installing the chaincode as a user chaincode does make the integration test a lot easier. Just realized though we might not be testing the right thing then. We are testing basically the chaincode itself which is what we have before. I thought the point of the integration was to test the plugin piece?

cbf (Wed, 06 Jun 2018 20:30:12 GMT):
a bit of both;-)

swetha (Wed, 06 Jun 2018 23:05:39 GMT):
So here are the integration tests by testing the plugin as an integration test: https://github.com/swetharepakula/fabric-chaincode-evm/tree/new-integration-tests. I am going to continue figuring out the build process though cause I don't think we get much more value from these tests from the unit tests if we don't test the plugin aspect.

swetha (Wed, 06 Jun 2018 23:05:39 GMT):
So here are the integration tests by testing the plugin as an integration test: https://github.com/swetharepakula/fabric-chaincode-evm/commit/0806ae8b92f6faeec2e30a6d117dd7d3342056b8. I am going to continue figuring out the build process though cause I don't think we get much more value from these tests from the unit tests if we don't test the plugin aspect.

swetha (Wed, 06 Jun 2018 23:06:18 GMT):
But I think those tests would be a better place for you to start from in terms of plugging in other smart contracts

swetha (Wed, 06 Jun 2018 23:06:31 GMT):
@guoger ^

guoger (Thu, 07 Jun 2018 02:17:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=DuctrKjjKYP4YCjL3) @swetha in terms of what we are writing tests for, here's what I understand: \[ \begin{matrix} & chaincode & e2e & plugin-loading \\ unit-tests & * & & \\ integration-test-with-user chaincode & * & * & \\ integration-test-with-sys chaincode & * & * & * \\ \end{matrix} \]

guoger (Thu, 07 Jun 2018 02:18:31 GMT):
as long as we make sure plugin is loadable with current e2e test, I feel we are safe to use user chaincode in integration tests.

guoger (Thu, 07 Jun 2018 02:19:46 GMT):
> I thought the point of the integration was to test the plugin piece? not only plugin piece. recall we discovered read-your-write bug with integration test.

swetha (Thu, 07 Jun 2018 02:21:13 GMT):
I think e2e is the same thing as plugin-loading

swetha (Thu, 07 Jun 2018 02:22:03 GMT):
@guoger, The point is to replace e2e though. We don't want those as our integration tests

swetha (Thu, 07 Jun 2018 02:22:03 GMT):
@guoger, The point is to replace e2e. We don't want those as our integration tests

swetha (Thu, 07 Jun 2018 02:22:11 GMT):
if we are having all 3 then I agree with you

swetha (Thu, 07 Jun 2018 02:23:02 GMT):
And if we are keeping the e2e, then I don't see value add in these integration tests because it running the exact tests as what we have in `evmscc_test.go`

swetha (Thu, 07 Jun 2018 02:23:29 GMT):
Only difference is using the peer cli, but our e2e would already be testing that

guoger (Thu, 07 Jun 2018 02:23:54 GMT):
> We don't want those as our integration tests why not? don't we need to make sure it work on Linux OS?

swetha (Thu, 07 Jun 2018 02:24:44 GMT):
these tests could run both on linux and mac

guoger (Thu, 07 Jun 2018 02:25:05 GMT):
> it running the exact tests as what we have in `evmscc_test.go` not really.. evmscc_test actually mocks everything, but integration test goes through the whole fabric tx flow

swetha (Thu, 07 Jun 2018 02:26:21 GMT):
It is mocking out the fabric tx flow which is tested in fabric. We shouldn't be testing that

swetha (Thu, 07 Jun 2018 02:27:13 GMT):
Right now I see these integration tests testing the ability to add chaincode to Fabric

swetha (Thu, 07 Jun 2018 02:27:42 GMT):
The plugin aspect I think is more important because that isn't tested in Fabric

guoger (Thu, 07 Jun 2018 02:28:07 GMT):
we have plugin tests in fabric

swetha (Thu, 07 Jun 2018 02:28:21 GMT):
those only test pluggable endorsement and validation

swetha (Thu, 07 Jun 2018 02:55:56 GMT):
@cbf, Jay and I have been talking about the integration tests. This build problem seems to keep coming up and we are concerned with the maintainability of that process, especially if we are doing that natively in go. As a compromise we are thinking of keeping the e2e_cli test for system chaincode pluggability and using the new ginkgo integration tests which use the evm as a user chaincode as a way to test out the features of evm with a fabric network. When we add more features or want to test different contracts we can extend just the ginkgo tests. What are your thoughts?

guoger (Thu, 07 Jun 2018 03:07:01 GMT):
also, I tried to load plugin natively on osx and it didn't work because of some exotic seg fault. @swetha is going to give it another try

swetha (Thu, 07 Jun 2018 04:00:51 GMT):
@guoger, Doesn't work natively. I start getting this error: ``` runtime: bad pointer in frame regexp/syntax.(*compiler).compile at 0xc42026dd30: 0x17 [e][peer-0] fatal error: invalid pointer found on stack ```

swetha (Thu, 07 Jun 2018 04:00:51 GMT):
@guoger, Doesn't work natively. I start getting this error: ``` [e][peer-0]runtime: bad pointer in frame regexp/syntax.(*compiler).compile at 0xc42026dd30: 0x17 [e][peer-0] fatal error: invalid pointer found on stack ```

guoger (Thu, 07 Jun 2018 04:01:58 GMT):
Hmmm, i think i got something different...don’t really remember clearly

guoger (Thu, 07 Jun 2018 04:02:11 GMT):
But I didn’t work for me neither

guoger (Thu, 07 Jun 2018 04:02:17 GMT):
It*

swetha (Thu, 07 Jun 2018 04:02:48 GMT):
im digging to make sure the problem is the plugin. but that error only showed up after changing the config to load the plugin

guoger (Thu, 07 Jun 2018 04:06:16 GMT):
also you could try exact same thing on Linux, so we know for sure it's the OS issue

swetha (Thu, 07 Jun 2018 04:08:13 GMT):
Oh wait one sec, I think I altered the wrong part of the integration code

swetha (Thu, 07 Jun 2018 04:09:36 GMT):
That is a good idea, I will try to run it in a docker image

guoger (Thu, 07 Jun 2018 04:30:04 GMT):
also, just ran a google search on golang plugin for darwin, and some issues may be related: https://github.com/golang/go/issues/23369 https://github.com/golang/go/issues/24257

guoger (Thu, 07 Jun 2018 04:31:30 GMT):
not sure if it's cherry-picked to 1.10.2 though...

cbf (Thu, 07 Jun 2018 13:02:07 GMT):
I would suggest we defer this (adopting integration test "framework") to 1.3

cbf (Thu, 07 Jun 2018 13:02:28 GMT):
I'd prefer we get some additional cycles testing various contracts

rangak (Thu, 07 Jun 2018 14:19:34 GMT):
Has joined the channel.

abraham (Fri, 08 Jun 2018 04:24:14 GMT):
Has joined the channel.

richzhao (Fri, 08 Jun 2018 14:41:45 GMT):
Has joined the channel.

silasdavis (Wed, 13 Jun 2018 23:38:25 GMT):
Having a look at dependency graph above is showing project level dependencies, which burrow packages are you actually depending on for fabric-evm?

silasdavis (Wed, 13 Jun 2018 23:39:06 GMT):
I'd be surprised if you were hitting x/net/trace from anything in the import graph of burrow/execution/evm

silasdavis (Wed, 13 Jun 2018 23:39:55 GMT):
not sure what behaviour is with plugin, but recent versions of dep can prune unused packages with: [prune] go-tests = true unused-packages = true non-go = true

silasdavis (Wed, 13 Jun 2018 23:39:55 GMT):
not sure what behaviour is with plugin, but recent versions of dep can prune unused packages with: ``` [prune] go-tests = true unused-packages = true non-go = true ```

silasdavis (Wed, 13 Jun 2018 23:40:21 GMT):
perhaps that will help you avoid the x/net/trace double initialisation

silasdavis (Wed, 13 Jun 2018 23:42:38 GMT):
certainly you shouldn't be seeing a grpc import unless you have the entire burrow project

silasdavis (Wed, 13 Jun 2018 23:42:38 GMT):
same with go-kit provided you are only including the required packages

swetha (Thu, 14 Jun 2018 01:33:27 GMT):
@silasdavis We are dependent on `account`, `binary`, `execution/evm`. Though I think just those 3 seem to pull in a few more. Currently what we have is ``` packages = [ "account", "account/state", "binary", "event", "execution/evm", "execution/evm/abi", "execution/evm/asm", "execution/evm/asm/bc", "execution/evm/events", "execution/evm/sha3", "logging", "logging/structure", "permission", "permission/types", "process" ] ```

swetha (Thu, 14 Jun 2018 01:34:06 GMT):
We do have prune options set in our config

pauljithink (Thu, 14 Jun 2018 01:42:51 GMT):
Has joined the channel.

swetha (Thu, 14 Jun 2018 05:25:30 GMT):
So I think I have verified the double x/net/trace is not coming from a dependency on burrow. That double initialization happens because the plugin is dependent on fabric.

guoger (Thu, 14 Jun 2018 06:06:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=gWqQMCBY9w7w8yMCm) @swetha mind elaborating?

cbf (Thu, 14 Jun 2018 11:20:58 GMT):
@swetha, you are getting this in the integration framework? it's definitely coming from Fabric and it is because Go considers the symbols to be different because the paths are different. Again, I think we should defer the integration test work to post 1.2 - not worth banging our heads against this now

swetha (Thu, 14 Jun 2018 16:03:27 GMT):
@cbf , No I just took a quick look at the dependencies for Silas's question

swetha (Thu, 14 Jun 2018 16:04:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=YPSjoKJqsujJDbqCL) @guoger I meant that we are pulling in a dependency from fabric, namely the shim, which pulls in x/net/trace which is loaded by fabric as well causing the double initialization

paulananth (Fri, 15 Jun 2018 12:17:37 GMT):
Has joined the channel.

cbf (Thu, 21 Jun 2018 17:14:15 GMT):
https://gerrit.hyperledger.org/r/23457

cbf (Thu, 21 Jun 2018 17:14:18 GMT):
please

cbf (Thu, 21 Jun 2018 21:02:56 GMT):
@guoger https://gerrit.hyperledger.org/r/c/23457/1/README.md#15 pls see my comment

guoger (Fri, 22 Jun 2018 01:26:09 GMT):
maybe something like: > Fabric proxy implements Ethereum compliant JSON RPC interfaces, so that users could use tools, such as Remix, Truffle, etc, to interact with Smart Contract running in EVM.

guoger (Fri, 22 Jun 2018 01:26:15 GMT):
^ @cbf

cbf (Fri, 22 Jun 2018 01:26:41 GMT):
ok

cbf (Fri, 22 Jun 2018 01:28:50 GMT):
done thanks

guoger (Fri, 22 Jun 2018 01:30:01 GMT):
+2'ed

cbf (Fri, 22 Jun 2018 01:33:10 GMT):
thx

guoger (Fri, 22 Jun 2018 02:55:56 GMT):
@swetha when you have some time, take a look at https://gerrit.hyperledger.org/r/23457 from chris, adding README

swetha (Fri, 22 Jun 2018 02:56:20 GMT):
oh will do, sorry didn't see that change

swetha (Fri, 22 Jun 2018 03:00:49 GMT):
Reviewed it, LGTM

nvxtien (Fri, 22 Jun 2018 11:25:52 GMT):
Has joined the channel.

sureshtedla (Sat, 23 Jun 2018 23:32:57 GMT):
Has joined the channel.

GiuseppeLittera (Mon, 25 Jun 2018 20:06:33 GMT):
Has joined the channel.

baoyangc (Tue, 26 Jun 2018 11:32:53 GMT):
Has joined the channel.

baoyangc (Tue, 26 Jun 2018 15:50:09 GMT):
```shell docker pull hyperledger/fabric-peer-evm:amd64-latest Error response from daemon: pull access denied for hyperledger/fabric-peer-evm, repository does not exist or may require 'docker login' ``` can't pull fabric-peer-evm

grice_32 (Tue, 26 Jun 2018 15:52:06 GMT):
Has joined the channel.

cbf (Tue, 26 Jun 2018 18:34:23 GMT):
yes, we haven't pushed it yet... need someone to create the repository for us

cbf (Wed, 27 Jun 2018 12:21:44 GMT):
@baoyangc the image has not been pushed

jaromil (Fri, 29 Jun 2018 11:53:03 GMT):
Has joined the channel.

mark.zhang (Sat, 30 Jun 2018 02:46:29 GMT):
Has joined the channel.

tianma323 (Sat, 30 Jun 2018 08:25:45 GMT):
Has joined the channel.

sigma67 (Sun, 01 Jul 2018 19:50:38 GMT):
Has joined the channel.

BabuPallam (Wed, 04 Jul 2018 22:20:46 GMT):
Has joined the channel.

swetha (Fri, 06 Jul 2018 20:03:09 GMT):
@guoger & @cbf : Just submitted initial patch for the proxy: https://gerrit.hyperledger.org/r/#/c/24185/

EricPetruzzelli (Sat, 07 Jul 2018 11:59:54 GMT):
Has joined the channel.

Telijas (Mon, 09 Jul 2018 14:21:10 GMT):
Has joined the channel.

cbf (Tue, 10 Jul 2018 12:52:59 GMT):
@swetha what are the accounts on the proxy?

cbf (Tue, 10 Jul 2018 12:53:06 GMT):
I need to run the client app locally

adamludvik (Tue, 10 Jul 2018 13:17:28 GMT):
Has left the channel.

swetha (Tue, 10 Jul 2018 17:16:56 GMT):
@cbf,looking for them

cbf (Tue, 10 Jul 2018 17:17:11 GMT):
thx

cbf (Tue, 10 Jul 2018 17:17:55 GMT):
I seem to be in a mode where the login screen does not successfully "login" and even if I open the vote page, it just beach-balls when I submit a vote

swetha (Tue, 10 Jul 2018 17:20:47 GMT):
Try one of these: 537627a1e9456be6fc015800d23cf91a93555fe6 613ac660a26a66a52eadc02cda9f6c7e7326e675 853c507c8abde6d6d82f2e84cc4ca65f82ae5a09 861256673241f8a9e3b086b1b01e76143253c8fc

swetha (Tue, 10 Jul 2018 17:20:47 GMT):
Try one of these: ``` 537627a1e9456be6fc015800d23cf91a93555fe6 613ac660a26a66a52eadc02cda9f6c7e7326e675 853c507c8abde6d6d82f2e84cc4ca65f82ae5a09 861256673241f8a9e3b086b1b01e76143253c8fc ```

swetha (Tue, 10 Jul 2018 17:22:37 GMT):
When you get a chance can you open up the inspect console on the browser and see if there are any error messages you see? I am not seeing the issue currently

cbf (Tue, 10 Jul 2018 17:36:39 GMT):
those are the ones I tried

cbf (Tue, 10 Jul 2018 17:39:50 GMT):
BAH

cbf (Tue, 10 Jul 2018 17:40:01 GMT):
I was putting the user in the password

cbf (Tue, 10 Jul 2018 17:40:08 GMT):
password is 'some-password'

cbf (Tue, 10 Jul 2018 17:40:11 GMT):
working now

cbf (Tue, 10 Jul 2018 17:40:14 GMT):
thanks

swetha (Tue, 10 Jul 2018 17:47:53 GMT):
haha, no problem

cbf (Tue, 10 Jul 2018 21:13:28 GMT):
@swetha the CR needs license headers for all the new files

swetha (Tue, 10 Jul 2018 21:13:44 GMT):
Oh yea, forgot about that. Adding them now thanks

cbf (Tue, 10 Jul 2018 21:14:07 GMT):
thx

swetha (Wed, 11 Jul 2018 01:56:25 GMT):
@cbf & @guoger Here is the vendor commit: https://gerrit.hyperledger.org/r/#/c/24183/

guoger (Wed, 11 Jul 2018 02:41:21 GMT):
@swetha how do you plan to do integration test for fabproxy? should we leverage `jest`, or we could go a step further and use `truffle`, etc

swetha (Wed, 11 Jul 2018 02:42:47 GMT):
I was thinking about a couple things. One was to send requests using our current ginkgo test framework and have those run against our e2e example

swetha (Wed, 11 Jul 2018 02:44:26 GMT):
Using truffle and remix is going to require a few more instructions & CORS support. The CORS piece is easy and just waiting on these commits to be merged before pushing that. In regards of using truffle, that will take a little longer

swetha (Wed, 11 Jul 2018 02:45:29 GMT):
The other thing this depends on is how the integration framework will be for the plugin as a whole. If we go down the ginkgo path then i would think it is better to stick to that and not introduce too many languages and types of tests

guoger (Wed, 11 Jul 2018 03:38:19 GMT):
IMO, including web3.js as part of our test pipeline makes more sense

guoger (Wed, 11 Jul 2018 03:38:53 GMT):
so that we are not testing our own expectations, but that of web3.js

swetha (Wed, 11 Jul 2018 04:03:44 GMT):
that is true, but what we really want to make sure is that we implemented the API properly

swetha (Wed, 11 Jul 2018 04:04:01 GMT):
I am going to keep thinking about that

swetha (Wed, 11 Jul 2018 04:56:02 GMT):
another ginkgo layer does seem redundant

jayeshjawale95 (Wed, 11 Jul 2018 07:30:29 GMT):
Has joined the channel.

guoger (Wed, 11 Jul 2018 08:16:55 GMT):
@swetha quick question, why do you create new client for every invocation, instead of reusing the same one? ``` func (s *fabSDK) GetChannelClient() (fabproxy.ChannelClient, error) { clientChannelContext := s.sdk.ChannelContext(s.channel, fabsdk.WithUser(s.user), fabsdk.WithOrg(s.org)) return channel.New(clientChannelContext) } ```

bramvdbogaerde (Wed, 11 Jul 2018 10:09:00 GMT):
Has joined the channel.

cbf (Wed, 11 Jul 2018 12:15:58 GMT):
I think that the goal is to support web3, so Jay's suggestion makes sense to me. I agree we want to make sure we have implemented the API properly. Maybe the distinction is ginkgo is UT and use of jasmine or the like for integration test?

cbf (Wed, 11 Jul 2018 12:18:44 GMT):
also, I think that we should move the plugin into the fabric repo. It is too clunky to build and make available, as it stands, and we also cannot take advantage of the ACL support, which is only available to SYSCC. I think that we still want to be able to restrict deploying a contract to admin (or some privileged account), no? @swetha @guoger

swetha (Wed, 11 Jul 2018 16:27:33 GMT):
@cbf, I think that would solve a lot of our problems

swetha (Wed, 11 Jul 2018 16:28:32 GMT):
@guoger, I thought it kind of starting a connection each time a request came in and not keep connections alive, but realized I never closed the clients, so will push up another patchtoday

swetha (Wed, 11 Jul 2018 16:49:51 GMT):
Nevermind. In this version of the sdk, we can never close the client. I am going to change it to just initialize the channel context once

swetha (Wed, 11 Jul 2018 20:30:21 GMT):
The current version of the SDK and the combination of Fabric 1.2 we have a problem of the sdk not being able invoke or query custom system chaincodes because the sdk queries the Discovery Service for available chaincodes but the `evmscc` will not show up on that list. So patch won't be ready today

yacovm (Wed, 11 Jul 2018 20:35:54 GMT):
System chaincodes have lifecycle, so it's not even possible to discover what peers have them and what peers don't, and obviously SD doesn't support SCCs and won't until we do the lifecycle change which would *maybe* give SCCs their own lifecycle

yacovm (Wed, 11 Jul 2018 20:35:54 GMT):
System chaincodes don't have lifecycle, so it's not even possible to discover what peers have them and what peers don't, and obviously SD doesn't support SCCs and won't until we do the lifecycle change which would *maybe* give SCCs their own lifecycle

yacovm (Wed, 11 Jul 2018 20:38:56 GMT):
The only way is to just not use SD for SCCs 😉

yacovm (Wed, 11 Jul 2018 20:38:56 GMT):
The only way in the meantime is to just not use SD for SCCs 😉

swetha (Wed, 11 Jul 2018 20:43:08 GMT):
I agree, I just don't know how to disable that in the SDK. The config didn't seem to have an obvious answers

BlockchainBusiness (Mon, 16 Jul 2018 02:31:57 GMT):
Has joined the channel.

vladyslavmunin (Wed, 18 Jul 2018 15:07:46 GMT):
Has joined the channel.

amongv587 (Thu, 19 Jul 2018 15:05:28 GMT):
Has joined the channel.

karadalex (Sat, 21 Jul 2018 11:57:27 GMT):
Has joined the channel.

chuojiang (Wed, 25 Jul 2018 07:32:28 GMT):
Has joined the channel.

cbf (Wed, 25 Jul 2018 13:21:44 GMT):
@swetha any reason that we need to use syscc for the evmcc?

cbf (Wed, 25 Jul 2018 13:26:43 GMT):
also, could you please add story points to all the evm jiras? thanks

guoger (Wed, 25 Jul 2018 15:55:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=c93JaeP2faGKoLfgs) @cbf initially, we did. However, we were trying to follow Fabric work flow as much as possible: - user deploys an evm contract with a canonical name - looks up the type of invoked contract by name, if `EVM`, redirecting it to evm cc this invaded fabric code. Also, we want to leverage that syscc being automatically deployed to every channel we create.

guoger (Wed, 25 Jul 2018 15:55:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=c93JaeP2faGKoLfgs) @cbf initially, we did. However, we were trying to follow Fabric work flow as much as possible: - implement a new type of cc `EVM`, along with `GOLANG` and `JAVA` - user deploys an evm contract with a canonical name - looks up the type of invoked contract by name, if `EVM`, redirecting it to evm cc this invaded fabric code. Also, we want to leverage that syscc being automatically deployed to every channel we create.

guoger (Wed, 25 Jul 2018 15:56:37 GMT):
although, given current design, we could actually revert to this. And I actually did it when I was too sick of bizarre build.

cbf (Wed, 25 Jul 2018 16:38:38 GMT):
Well, when we deploy a contract, it isn't same as deploying chaincode

cbf (Wed, 25 Jul 2018 16:38:42 GMT):
it is a transaction

cbf (Wed, 25 Jul 2018 16:39:07 GMT):
so we could have single evmcc container and a specific method that deployed the contract(s)

cbf (Wed, 25 Jul 2018 16:39:22 GMT):
@guoger @swetha

cbf (Wed, 25 Jul 2018 16:40:08 GMT):
I am not thrilled with the UX of the plugin TBH and this makes the whole deployment question much more naturally integrated with CC lifecycle

cbf (Wed, 25 Jul 2018 16:40:13 GMT):
and discovery

swetha (Wed, 25 Jul 2018 17:21:49 GMT):
@cbf I agree that the plugin ux isn't great. Are you thinking we should move away from the syscc completely or that just the plugin aspect of the design?

swetha (Wed, 25 Jul 2018 17:23:17 GMT):
Also is there a scale we typically use for story points?

cbf (Wed, 25 Jul 2018 18:01:31 GMT):
yes, let's just make a plain old chaincode shim/container

cbf (Wed, 25 Jul 2018 18:02:23 GMT):
as for story points, use your best guestimate 1=dayish 2=two 4=week 8=two or more ish

swetha (Wed, 25 Jul 2018 18:08:01 GMT):
Okay I will look into how we can incorporate this into the usual lifecycle workflow we use for Go

swetha (Wed, 25 Jul 2018 18:08:38 GMT):
We may need to postpone the design review tomorrow then

swetha (Wed, 25 Jul 2018 18:25:04 GMT):
@cbf, wait do you mean a regular chaincode?

cbf (Wed, 25 Jul 2018 20:12:35 GMT):
I mean deploy it as regular Go chaincode

cbf (Wed, 25 Jul 2018 20:12:49 GMT):
can we do that?

swetha (Wed, 25 Jul 2018 20:58:11 GMT):
oh okay, yes we can do that in its current situation

MHBauer (Wed, 25 Jul 2018 20:58:34 GMT):
Has joined the channel.

swetha (Wed, 25 Jul 2018 20:58:55 GMT):
but for future features like admin only contract deployment we would never be able to do that

ricktobacco (Wed, 25 Jul 2018 23:35:23 GMT):
Has joined the channel.

ricktobacco (Wed, 25 Jul 2018 23:36:48 GMT):
hello, thank you for making this plugin!

ricktobacco (Wed, 25 Jul 2018 23:37:46 GMT):
i am interested in overcoming the following limitations of stock version chaincode (my question is how to go about it if indeed possible)

ricktobacco (Wed, 25 Jul 2018 23:39:13 GMT):
With Gas, it is possible to control the execution of a smart contract. Gas allows you to re-enter smart contract code as many times as necessary, which produces elegant solutions with contract-to-contract interoperability. It is not possible to re-enter chaincode. Say we need to call the second contract from the first and then do a call-back to the first. In EVM, everything acts as an account, including smart contract, allowing a contract to act as a user and own assets. When one smart contract calls another smart contract on EVM, it assumes its own identity versus that of the user (who is calling the first smart contract). This way, a smart contract can always identify what code is calling it. In chaincode, there is currently no built-in way to distinguish between the chaincodes. Thus, the code always assumes the calling user identity.

swetha (Wed, 25 Jul 2018 23:58:49 GMT):
@ricktobacco: When you use the plugin, there is a different between the EVM smart contract and the chaincode

swetha (Wed, 25 Jul 2018 23:58:49 GMT):
@ricktobacco: When you use the plugin, there is a difference between the EVM smart contract and the chaincode

swetha (Wed, 25 Jul 2018 23:59:32 GMT):
The plugin itself is the chaincode that runs EVM smart contracts, so we don't go through the usual lifecycle workflow for deploying new EVM bytecode contracts

swetha (Thu, 26 Jul 2018 00:01:22 GMT):
For accounts, Fabric has no concept of accounts as you already mentioned. What we do is we set whoever is invoking the evmscc as the account calling the initial contract

swetha (Thu, 26 Jul 2018 00:02:25 GMT):
In terms of what a contract calling a contract, I don't know what happens on the top of my mind. I have to go through the Burrow EVM code again and get back to you

swetha (Thu, 26 Jul 2018 00:03:07 GMT):
I am curious, what are you trying to do with the plugin. We would love feedback!

swetha (Thu, 26 Jul 2018 00:06:04 GMT):
Also for the time being Gas is hardcoded at 90000 per transaction with the plugin

Ryan2 (Thu, 26 Jul 2018 06:09:03 GMT):
Has joined the channel.

sujanpgowda (Mon, 30 Jul 2018 13:37:53 GMT):
Has joined the channel.

gatakka (Tue, 31 Jul 2018 06:26:23 GMT):
Has joined the channel.

compleatang (Tue, 31 Jul 2018 15:39:33 GMT):
assuming y'all haven't done anything crazy with the state (e.g., sharding it and only letting a particular node see part of the EVM state) and it is all available to the EVM container, then the call path will run until completion or exception and then return to you (you being the chaincode level). we test multiple depths or contracts calling contracts and this should be all handled in Burrow EVM. If you run into any challenges tho definitely let us know.

compleatang (Tue, 31 Jul 2018 15:40:11 GMT):
tl'dr contracts calling contracts should work just fine as it is an internal EVM operation and the EVM execution path won't return until it reaches completion of the code path (or an exception)

swetha (Tue, 31 Jul 2018 18:22:29 GMT):
@compleatang Thanks for that!

compleatang (Tue, 31 Jul 2018 21:02:50 GMT):
np

samwood (Wed, 01 Aug 2018 17:33:49 GMT):
Has joined the channel.

zmaro (Fri, 03 Aug 2018 15:20:55 GMT):
Has joined the channel.

pankajanand26 (Fri, 03 Aug 2018 15:34:34 GMT):
Has joined the channel.

soc1024 (Mon, 06 Aug 2018 08:35:22 GMT):
hey i have a question about how read set / write sets are handled in fabric evm

soc1024 (Mon, 06 Aug 2018 08:36:06 GMT):
i tried to look for this terminology in the design doc but couldn't find it, might be using some of the terms wrong

soc1024 (Mon, 06 Aug 2018 08:36:49 GMT):
is there one key for basically the entire EVM space? or one for each contract/account? I'm curious what happens when there are simultaneously multiple transactions sent to the endorsers, and at some point they have to determine whether they are in conflict or not

guoger (Mon, 06 Aug 2018 09:04:31 GMT):
> is there one key for basically the entire EVM space No, in short, we use composite key `address + key`, where `address` is associated with user account or contract account, and `key` is whatever evm stores a value with. So account is almost a namespace here. > at some point they have to determine whether they are in conflict or not they are still validated using fabric validation, meaning version check on RWset by default.

guoger (Mon, 06 Aug 2018 09:04:31 GMT):
hi, @soc1024 > is there one key for basically the entire EVM space No. in short, we use composite key `address + key`, where `address` is associated with user account or contract account, and `key` is whatever evm stores a value with. So account is almost a namespace here. > at some point they have to determine whether they are in conflict or not they are still validated using fabric validation, meaning version check on RWset by default.

soc1024 (Mon, 06 Aug 2018 09:06:56 GMT):
thanks for the response!

soc1024 (Mon, 06 Aug 2018 09:07:29 GMT):
so with `address + key`, `address` is associated with the sender?

soc1024 (Mon, 06 Aug 2018 09:08:09 GMT):
maybe i can answer some of my remaining questions by looking at the code, do you have a suggestion where to find RWset, i'll search for tht now

guoger (Mon, 06 Aug 2018 09:09:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=oFD976PubXroEisfC) @soc1024 could be, it should depend on the logic in your smart contract.

soc1024 (Mon, 06 Aug 2018 09:09:39 GMT):
okay

guoger (Mon, 06 Aug 2018 09:09:46 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=aEjyRzmujchBiERMy) @soc1024 RWset is produced when chaincode shim is invoked.

soc1024 (Mon, 06 Aug 2018 09:10:45 GMT):
i'm trying to track down whether my intuition is correct, which is that if there are a lot of simultaneous transactions to the same contract (e.g., there is an Auction contract and lots of people are trying to make incrementally higher bids) then there will be lots of contention, hence many endorsements will fail at the validation stage and have to be re-endorsed again

guoger (Mon, 06 Aug 2018 09:10:46 GMT):
Burrow evm library depends on https://github.com/hyperledger/fabric-chaincode-evm/blob/master/statemanager/statemanager.go#L15-L21

guoger (Mon, 06 Aug 2018 09:11:58 GMT):
if you are repeatedly modifying one variable, say `highest_bid`, then yes

guoger (Mon, 06 Aug 2018 09:12:25 GMT):
but if you maintain a `map[user_addr]bid`, then not

soc1024 (Mon, 06 Aug 2018 09:12:40 GMT):
makes sense, OK

guoger (Mon, 06 Aug 2018 09:13:38 GMT):
to expand on previous question, the code is fairly simple. We translate Burrow ledger interface to Fabric chaincode shim, so it produces RWset as usual

soc1024 (Mon, 06 Aug 2018 09:13:41 GMT):
in practice most contracts will do something like `map[user_addr]bid` but also `int totalbids`

soc1024 (Mon, 06 Aug 2018 09:13:41 GMT):
in practice most contracts will do something like `map[user_addr]bid` but also `uint totalbids`

guoger (Mon, 06 Aug 2018 09:14:47 GMT):
yeah... we are aware of the limitation here.. ethereum serialize transactions so it's not a problem for them :P

guoger (Mon, 06 Aug 2018 09:15:19 GMT):
with special validation/endorsement plugins, this could be mitigated in Fabric as well

guoger (Mon, 06 Aug 2018 09:15:19 GMT):
with custom validation/endorsement plugins, this could be mitigated in Fabric as well

soc1024 (Mon, 06 Aug 2018 09:16:47 GMT):
interesting, i was wondering about this for other applications as well,

soc1024 (Mon, 06 Aug 2018 09:17:01 GMT):
it would be nice to have endorsers run their own BFT as a "pre ordering" or something to address such contention

soc1024 (Mon, 06 Aug 2018 09:17:10 GMT):
i assume that is what you mean by endorsement plugin s

soc1024 (Mon, 06 Aug 2018 09:17:20 GMT):
any links to such? i wasn't aware of any

soc1024 (Mon, 06 Aug 2018 09:17:46 GMT):
also is there any discussion / writeup about these limitations? or keywords that people would use to describe it? thanks!

soc1024 (Mon, 06 Aug 2018 09:17:46 GMT):
also is there any discussion / writeup about these limitations? or keywords that people would use to describe it? (perhaps not limited to just EVM setting) thanks!

guoger (Mon, 06 Aug 2018 09:18:29 GMT):
> run their own BFT as a "pre ordering" mind elaborate?

guoger (Mon, 06 Aug 2018 09:19:08 GMT):
> also is there any discussion / writeup about these limitations? Unfortunately no, at least to my knowledge. :(

soc1024 (Mon, 06 Aug 2018 09:20:58 GMT):
In the hyperledger fabric arxi paper https://arxiv.org/pdf/1801.10228.pdf this is mentioned: ``` s. As the endorsers simulate the proposal without synchronizing with other endorsers, two endorsers may execute it on different states of the ledger and produce different outputs. For the standard endorsement policy which requires multiple endorsers to produce the same result, this implies that under high contention of operations accessing the same keys, a client may not be able to satisfy the endorsement policy. This is a new consideration compared to primary-backup replication in replicated databases with synchronization through middleware [40]: a consequence of the assumption that no single peer is trusted for correct execution in a blockchain. We consciously adopted this design, as it considerably simplifies the architecture and is adequate for typical blockchain applications. As demonstrated by the approach of Bitcoin, distributed applications can be formulated such that contention by operations accessing the same state can be reduced, or eliminated completely in the normal case (e.g., in Bitcoin, two operations that modify the same “object” are not allowed and represent a double-spending attack [44]). In the future, we plan to gradually enhance the liveness semantics of Fabric under contention, in particular to support CRDTs [51] for complementing the current version dependency checks, as well as a per-chaincode lead-endorser that would act as a transaction sequencer ```

soc1024 (Mon, 06 Aug 2018 09:20:58 GMT):
In the hyperledger fabric arxi paper https://arxiv.org/pdf/1801.10228.pdf this is mentioned: ``` As the endorsers simulate the proposal without synchronizing with other endorsers, two endorsers may execute it on different states of the ledger and produce different outputs. For the standard endorsement policy which requires multiple endorsers to produce the same result, this implies that under high contention of operations accessing the same keys, a client may not be able to satisfy the endorsement policy. This is a new consideration compared to primary-backup replication in replicated databases with synchronization through middleware [40]: a consequence of the assumption that no single peer is trusted for correct execution in a blockchain. We consciously adopted this design, as it considerably simplifies the architecture and is adequate for typical blockchain applications. As demonstrated by the approach of Bitcoin, distributed applications can be formulated such that contention by operations accessing the same state can be reduced, or eliminated completely in the normal case (e.g., in Bitcoin, two operations that modify the same “object” are not allowed and represent a double-spending attack [44]). In the future, we plan to gradually enhance the liveness semantics of Fabric under contention, in particular to support CRDTs [51] for complementing the current version dependency checks, as well as a per-chaincode lead-endorser that would act as a transaction sequencer ```

soc1024 (Mon, 06 Aug 2018 09:22:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=MRx78E9Ahs5Qp9LTd) Basically among a set of endorsers, they could run a BFT protocol among themselves to tentatively agree on a sequence of transactions before signing them. This would invovle, as suggested above, picking one of them as the leader at any given time, and having some policy for switching leaders if the leader crasehs

cbf (Mon, 06 Aug 2018 18:20:50 GMT):
https://gerrit.hyperledger.org/r/c/25115/ please

swetha (Mon, 06 Aug 2018 18:25:04 GMT):
just finished reviewing it

cbf (Mon, 06 Aug 2018 18:54:59 GMT):
merged, we now have automated CI - yay

swetha (Mon, 06 Aug 2018 21:55:54 GMT):
@cbf @guoger: I have been working on a work around the SDK using the discovery service. But if we are going to start recommending people to use the chaincode as a user chaincode, this work around should no longer be necessary

swetha (Mon, 06 Aug 2018 21:57:23 GMT):
Is user chaincode the way we are going to go? The only thing that I can think of as a problem is the admin only deployment of transactions. Which we can't do with plugins anyway, but could do if we made this into a regular system chaincode

cbf (Mon, 06 Aug 2018 22:18:35 GMT):
I think we should go the way of user chaincode

colinster (Tue, 07 Aug 2018 21:15:05 GMT):
Has joined the channel.

swetha (Thu, 09 Aug 2018 03:09:27 GMT):
I think we have an issue with the Jenkins build: https://jenkins.hyperledger.org/job/fabric-chaincode-evm-verify-master-x86_64/2/execution/node/11/log/.

swetha (Thu, 09 Aug 2018 03:12:01 GMT):
We need a different way to set the $PATH variable

puneet (Thu, 09 Aug 2018 09:35:55 GMT):
Has joined the channel.

silliman (Thu, 09 Aug 2018 13:07:22 GMT):
Has joined the channel.

cbf (Thu, 09 Aug 2018 13:21:12 GMT):
ping Ramesh on #fabric-ci I haven't looked closely but it may be in the Jenkinsfile - meaning we can fix it ourselves

cbf (Thu, 09 Aug 2018 13:21:30 GMT):
@swetha ^^

swetha (Thu, 09 Aug 2018 16:20:26 GMT):
Thanks!

guoger (Fri, 10 Aug 2018 07:14:29 GMT):
reviewing https://gerrit.hyperledger.org/r/c/25315/ I suppose we will be moving to ginkgo-style integration test in follow up patches?

guoger (Fri, 10 Aug 2018 07:14:33 GMT):
cc @swetha

cbf (Fri, 10 Aug 2018 12:13:48 GMT):
@guoger yeah, I think that @swetha had some of that WIP b4... but now that we are using user chaincode, we can practically cut-n-paste the fabric integration testing of chaincode

swetha (Fri, 10 Aug 2018 19:15:21 GMT):
Yes, trying to put in the commits one at a time. The stuff I had as a wip will be easy to convert and switch over, but don't want to do everything in one commit

KellyCooper (Mon, 13 Aug 2018 14:45:01 GMT):
Has joined the channel.

guoger (Wed, 15 Aug 2018 05:30:24 GMT):
https://gerrit.hyperledger.org/r/c/25315/ LGTM, cc @cbf @swetha

guoger (Wed, 15 Aug 2018 09:45:06 GMT):
@swetha i just realized that hyperledger/fabric-ccenv containers are leaked as well, could you confirm?

swetha (Wed, 15 Aug 2018 18:21:55 GMT):
ill double check but the e2e test should clean up all the evmcc containers it creates

swetha (Wed, 15 Aug 2018 18:37:26 GMT):
I don't have any leaked containers or images on my end. How are you running the e2e?

guoger (Thu, 16 Aug 2018 05:10:37 GMT):
ah, I see, I ctrl-c the e2e in the middle of building cc image, and ccenv is not reaped by `network_setup.sh down`. I guess it's not a problem

guoger (Thu, 16 Aug 2018 05:10:50 GMT):
CR is still +2'ed i think

swetha (Thu, 16 Aug 2018 16:15:53 GMT):
the evmcc images and containers are removed

KeenWarrior (Fri, 17 Aug 2018 07:55:17 GMT):
Has joined the channel.

minskeyguo (Sat, 18 Aug 2018 20:28:21 GMT):
Has joined the channel.

bdjidi (Tue, 21 Aug 2018 22:48:01 GMT):
Has joined the channel.

swetha (Wed, 22 Aug 2018 03:53:38 GMT):
https://jira.hyperledger.org/browse/FAB-11082

raheelz (Wed, 22 Aug 2018 20:24:04 GMT):
Has joined the channel.

compleatang (Thu, 23 Aug 2018 08:59:19 GMT):
@swetha @gouger @cbf just to let you all know (and anyone else), that we've set up the #burrow-downstream room. As the burrow EVM gets more use from downstream projects we wanted to set up a place where your team and the Sawtooth team could raise any issues with using the EVM as a library and where we could make sure you all were aware of any changes we've made to the EVM that are relevant for you as part of our release cycle. Hope y'all will join!

compleatang (Thu, 23 Aug 2018 08:59:19 GMT):
@swetha @guoger @cbf just to let you all know (and anyone else), that we've set up the #burrow-downstream room. As the burrow EVM gets more use from downstream projects we wanted to set up a place where your team and the Sawtooth team could raise any issues with using the EVM as a library and where we could make sure you all were aware of any changes we've made to the EVM that are relevant for you as part of our release cycle. Hope y'all will join!

guoger (Thu, 23 Aug 2018 09:13:14 GMT):
awesome! thx @compleatang

swetha (Thu, 23 Aug 2018 17:06:28 GMT):
Thats great! thanks @compleatang !

SarahM (Sat, 25 Aug 2018 17:45:30 GMT):
Has joined the channel.

cbf (Mon, 27 Aug 2018 11:33:48 GMT):
hey all, back from vacation... interested in getting a level-set on progress

guoger (Mon, 27 Aug 2018 14:39:45 GMT):
reviewing swetha's CR for fabproxy

guoger (Mon, 27 Aug 2018 14:40:48 GMT):
https://gerrit.hyperledger.org/r/c/25315/ this LGTM, +2'ed

guoger (Mon, 27 Aug 2018 14:41:30 GMT):
https://gerrit.hyperledger.org/r/c/25717 just clean up, LGTM

guoger (Mon, 27 Aug 2018 14:42:04 GMT):
still need some time to review remainings

asamk (Mon, 27 Aug 2018 14:56:01 GMT):
Has joined the channel.

swetha (Mon, 27 Aug 2018 17:12:24 GMT):
Those are the initial 2 patches that need to be review. I think in total I have 6 that have to do with the fabproxy as well as cleaning up the evm to be used as a user chaincode

silasdavis (Tue, 28 Aug 2018 11:59:09 GMT):
Hi guys... been ought of the loop for too long, just been trying to catch up with all the progress of fabric-evm

silasdavis (Tue, 28 Aug 2018 11:59:44 GMT):
regarding support for web3 - looks like you have integration at the web.js level looking at: https://github.com/christo4ferris/votevm

silasdavis (Tue, 28 Aug 2018 12:00:20 GMT):
which is an approach we were considering too - are you still planning to provide a proxy server serving the json-rpc?

guoger (Tue, 28 Aug 2018 13:48:08 GMT):
@silasdavis yes! and it's currently under review https://gerrit.hyperledger.org/r/c/24185/

silasdavis (Tue, 28 Aug 2018 14:00:40 GMT):
@guoger great...

silasdavis (Tue, 28 Aug 2018 14:00:53 GMT):
It's something that we really ought to get a basic version of into Burrow

silasdavis (Tue, 28 Aug 2018 14:01:33 GMT):
what might be nice is if we were to share your EthService interface and implement against our underlying API

silasdavis (Tue, 28 Aug 2018 14:01:37 GMT):
then we could share tests

silasdavis (Tue, 28 Aug 2018 14:01:42 GMT):
we would use gorilla too

swetha (Wed, 29 Aug 2018 06:38:57 GMT):
@silasdavis That was my thought process behind the interface, but we would love feedback about whether that works for you a not

swetha (Wed, 29 Aug 2018 06:38:57 GMT):
@silasdavis That was my thought process behind the interface, but we would love feedback about whether that interface works or not

swetha (Wed, 29 Aug 2018 06:39:38 GMT):
There are some fabric specific things that are tied in, but I did want to make it usable outside of fabric

silasdavis (Wed, 29 Aug 2018 16:45:11 GMT):
It would _feel_ good to share elements of implementation too - and when we come to implement `sendTransactionRaw` which will require some kind of serialisation (RLP) and signing converters then we may want to - but I think that our implementation of the interface would end up being pretty thin in Burrow just like yours is against Fabric

silasdavis (Wed, 29 Aug 2018 16:46:02 GMT):
I will try and find some (of somebody's - possibly my) time to see if I can implement something comparable to what you have - would make a lot of sense to share tests (I wonder if it would make sense for them to live somewhere in Burrow?)

silasdavis (Wed, 29 Aug 2018 16:48:25 GMT):
the other thing I was looking at is providing a web3.js 'Provider' against our GRPC interfaces. We now have something very close to that as part of https://github.com/monax/bosmarmot/tree/develop/burrow.js. In some ways this might be the neater integration point. Rather than trying to aim for full general web3 compliance (which will be necessarily partial anyway) I was going to shoot for getting truffle mostly working with us: https://truffleframework.com/ since it has this provider injection already for making mist/metamask work. I don't actually think it needs much of web3 to work...

swetha (Wed, 29 Aug 2018 17:04:58 GMT):
Sure I would love to work with whoever has some time to see how well this could port over to Burrow. In terms of tests, we haven't created integration tests yet but are thinking about using web3 to verify that our proxy implements the APIs correctly. We also are starting to look into how Truffle can work with the proxy. The idea of the injected provider is an interesting approach, and as you mention we won't get full web3 compliance just because of how the networks work. I have to think a little more about how that would work with Fabric though since we only integrated the VM portion of Burrow, and don't get access to the GRPC interfaces.

swetha (Wed, 29 Aug 2018 17:04:58 GMT):
Sure I would love to work with you or someone else to see how well this could port over to Burrow. In terms of tests, we haven't created integration tests yet but are thinking about using web3 to verify that our proxy implements the APIs correctly. We also are starting to look into how Truffle can work with the proxy. The idea of the injected provider is an interesting approach, and as you mention we won't get full web3 compliance just because of how the networks work. I have to think a little more about how that would work with Fabric though since we only integrated the VM portion of Burrow, and don't get access to the GRPC interfaces.

cbf (Wed, 29 Aug 2018 17:51:13 GMT):
+1000 to collaborating:-)

compleatang (Wed, 29 Aug 2018 19:14:20 GMT):
Swetha do you guys have a general purpose js client lib? Basically truffles providers allows you to inject your RPC specific calls into their interpretation. It's a pretty thin layer we think if you already have a client side js lib.

swetha (Thu, 30 Aug 2018 05:39:19 GMT):
We have a node SDK to talk to fabric, which could probably work. The proxy we are developing is written in go though. I haven't spent time on looking into the truffle integration and what we would need there. Our first priority was web3 and then remix

swetha (Thu, 30 Aug 2018 06:14:08 GMT):
@cbf @guoger pushed up some new patches this morning. because of the ordering I think all the commits need another review

swetha (Thu, 30 Aug 2018 06:15:07 GMT):
Also in terms of docs do we want to add something to fabric docs or do we just want something in the chaincode-evm readme for now?

guoger (Thu, 30 Aug 2018 06:15:55 GMT):
docs of?

swetha (Thu, 30 Aug 2018 06:24:36 GMT):
I am thinking the evm chaincode, how they should install and how to connect up the proxy

guoger (Thu, 30 Aug 2018 06:26:58 GMT):
ah, ok, any particular reason why it should go into fabric docs?

guoger (Thu, 30 Aug 2018 06:27:23 GMT):
what time is it for you?

swetha (Thu, 30 Aug 2018 06:42:43 GMT):
Its almost midnight for me

swetha (Thu, 30 Aug 2018 06:43:01 GMT):
No particular reason, but I think people who would be interested would first go to the fabric docs

guoger (Thu, 30 Aug 2018 06:45:51 GMT):
can we embed a pointer to `chaincode-evm` readme [here](https://github.com/hyperledger/fabric/blob/release-1.2/docs/source/chaincode.rst), saying something like: > Chaincode is a program, written in Go, node.js, *Contract-Oriented Languages*, and eventually in other programming languages such as Java,

guoger (Thu, 30 Aug 2018 06:45:51 GMT):
can we embed a pointer to `chaincode-evm` readme [here](https://github.com/hyperledger/fabric/blob/release-1.2/docs/source/chaincode.rst), saying something like: > Chaincode is a program, written in Go, node.js, *Contract-Oriented Languages*(pointer goes here), and eventually in other programming languages such as Java,

swetha (Thu, 30 Aug 2018 06:46:17 GMT):
I like that idea

guoger (Thu, 30 Aug 2018 06:47:25 GMT):
(could also be following _Java_, I don't have preference here)

swetha (Thu, 30 Aug 2018 06:52:14 GMT):
hahah, I don't have a preference on that either

cbf (Thu, 30 Aug 2018 12:03:57 GMT):
yeah, we need to update the docs... but a README would be warranted as well

cbf (Thu, 30 Aug 2018 12:04:33 GMT):
please update the README and I will discuss with the doc team where it belongs

compleatang (Thu, 30 Aug 2018 12:07:57 GMT):
Swetha, I'd need to check on remix specifically, but the way eth systems are generally one implements a `provider` that maps / wraps RPC calls to specific end points. This would mean you wouldn't have to do too much "server" side.

swetha (Thu, 30 Aug 2018 16:43:51 GMT):
Sorry I think I got a little confused. The proxy we are working on that Jay linked above is our web3 provider. Our first priority was to test it against web3 (basic set of APIs to make this work), then add APIs to make Remix, and follow that pattern for the other tools we want to support. In terms of truffle, we would want to be able to use this proxy as well

compleatang (Thu, 30 Aug 2018 18:12:56 GMT):
Ok.

guoger (Mon, 03 Sep 2018 08:58:28 GMT):
@swetha is [this CR](https://gerrit.hyperledger.org/r/c/25767/) reviewable or it's still WIP

swetha (Mon, 03 Sep 2018 19:54:06 GMT):
That one is reviewable. There is a timing issue when running the tests in jenkins which is causing build failures. Trying to fix those, so the last 2 will need to be reviewed again.

guoger (Tue, 04 Sep 2018 02:17:01 GMT):
@swetha review done. - left another comment [here](https://gerrit.hyperledger.org/r/c/24185/18/fabproxy/codec.go#34) but I'm ok if it's not addressed. Also, if you want change err assertions in `ethservice_test.go` to `Expect(err).To(MatchError(ContainString()))` in ensuing CRs, I'm also fine with that. - [this](https://gerrit.hyperledger.org/r/c/25767/) LGTM, +2'ed will merge remaining CRs all together. Good job!

swetha (Tue, 04 Sep 2018 03:06:52 GMT):
Thanks, I will add the check you were suggesting. I think that makes sense. That is an easy error to return

swetha (Tue, 04 Sep 2018 03:20:20 GMT):
@guoger , made the changes. let me know if i missed something

guoger (Tue, 04 Sep 2018 03:39:30 GMT):
@swetha +2'ed everything, let's wait for @cbf to give another round of review and they are ready to be merged.

guoger (Tue, 04 Sep 2018 03:40:38 GMT):
also, do you guys have a plan for other APIs to support remix?

guoger (Tue, 04 Sep 2018 03:40:43 GMT):
what's Morgan's chat ID?

swetha (Tue, 04 Sep 2018 03:41:02 GMT):
its @MHBauer

swetha (Tue, 04 Sep 2018 03:41:26 GMT):
For this release I am only planning on the ones needed for remix

guoger (Tue, 04 Sep 2018 03:42:02 GMT):
is @MHBauer going to do it?

swetha (Tue, 04 Sep 2018 03:43:03 GMT):
Yup, and I will help him with that once I finish a few more things for this release

guoger (Tue, 04 Sep 2018 03:43:22 GMT):
cool

swetha (Fri, 07 Sep 2018 04:22:08 GMT):
@guoger @cbf these patches are ready for review now: https://gerrit.hyperledger.org/r/26086 https://gerrit.hyperledger.org/r/26087 https://gerrit.hyperledger.org/r/26088

magicianx25 (Sun, 09 Sep 2018 14:48:15 GMT):
Has joined the channel.

guoger (Mon, 10 Sep 2018 05:55:51 GMT):
@swetha @MHBauer I think it's time to consider using a logger

swetha (Mon, 10 Sep 2018 06:39:18 GMT):
i agree! and since fabric is using zap now we can start using zap!

guoger (Mon, 10 Sep 2018 06:42:55 GMT):
does _nwo_ have hard dependencies of couch+kafka/zk, even though we are just using solo in integration test?

knagware9 (Mon, 10 Sep 2018 14:03:41 GMT):
Has joined the channel.

swetha (Mon, 10 Sep 2018 19:48:35 GMT):
@guoger, I believe so. I took the simplest test they had it is using couch+kafka/zk. I will take another look and see if it is possible to get rid of all those pieces

swetha (Mon, 10 Sep 2018 19:48:35 GMT):
@guoger, I believe so. I don't think those images are used during the test, but I will take another look. I think the integration packages checks for those images before needing them which forces us to pull them even though we don't need it.

donsonZhang (Tue, 11 Sep 2018 04:23:16 GMT):
Has joined the channel.

JaydipMakadia (Thu, 13 Sep 2018 13:10:41 GMT):
Has joined the channel.

guoger (Sat, 15 Sep 2018 10:05:20 GMT):
@MHBauer https://jira.hyperledger.org/browse/FAB-7983

guoger (Sat, 15 Sep 2018 10:07:07 GMT):
if it's not soo complicated and prevent us from releasing code, let's do it

guoger (Sat, 15 Sep 2018 10:15:03 GMT):
`return fmt.Errorf("need 2 params, got %q", numParams)` why `%q`?

swetha (Mon, 17 Sep 2018 17:44:47 GMT):
@guoger, I was thinking we should tackle the logger after getting all the other jiras done

swetha (Mon, 17 Sep 2018 17:51:16 GMT):
Where is the above line from?

guoger (Tue, 18 Sep 2018 00:02:00 GMT):
That’s from one of Morgan’s CR

djohnkang (Tue, 18 Sep 2018 06:14:00 GMT):
Has joined the channel.

guoger (Wed, 19 Sep 2018 01:35:09 GMT):
@swetha just wanna make sure, in ethereum, they say "web3 provider", not "JSON RPC provider", correct?

guoger (Wed, 19 Sep 2018 01:38:43 GMT):
just a wild idea, maybe we could call fabproxy `fab3` (echoing `web3`)? :P

swetha (Wed, 19 Sep 2018 02:40:44 GMT):
yes web3 provider is I've seen it be called

swetha (Wed, 19 Sep 2018 02:41:02 GMT):
i kind of like fab3

swetha (Wed, 19 Sep 2018 02:41:07 GMT):
time to rebrand :P

guoger (Wed, 19 Sep 2018 03:03:58 GMT):
@swetha just posted some comments https://gerrit.hyperledger.org/r/c/26172/

guoger (Wed, 19 Sep 2018 03:04:42 GMT):
if we all like `fab3`, let's rename it. wdyt @cbf @MHBauer

swetha (Wed, 19 Sep 2018 03:22:58 GMT):
Only thing to note is that fab3 is not a parallel to web3. But I like the name

guoger (Wed, 19 Sep 2018 03:26:19 GMT):
can we say `fab3 == web3 provider`?

swetha (Wed, 19 Sep 2018 03:29:24 GMT):
yes

MHBauer (Wed, 19 Sep 2018 03:44:38 GMT):
lulz

MHBauer (Wed, 19 Sep 2018 03:45:18 GMT):
you do you. but if we're renaming folders, let's make it more 'conventional go project layout'

MHBauer (Wed, 19 Sep 2018 03:45:39 GMT):
very frustrating day today.

guoger (Wed, 19 Sep 2018 03:53:27 GMT):
theoretically, with current master branch, should remix work?

MHBauer (Wed, 19 Sep 2018 04:12:44 GMT):
current master? With my two patches, yes, sort of.

MHBauer (Wed, 19 Sep 2018 04:12:58 GMT):
Depends on what you define as 'work'.

MHBauer (Wed, 19 Sep 2018 04:13:05 GMT):
I can make a short video if it would help.

guoger (Wed, 19 Sep 2018 04:22:29 GMT):
I'm trying to deploy simplestorage via remix and got some errors

guoger (Wed, 19 Sep 2018 04:22:44 GMT):
so I just wanna make sure it _should_ work before I give another try later

MHBauer (Wed, 19 Sep 2018 06:42:45 GMT):
should work with the current patches, tho I may have pushed something today that blew everything up trying to refactor.

MHBauer (Wed, 19 Sep 2018 06:42:48 GMT):
let me try

MHBauer (Wed, 19 Sep 2018 06:46:19 GMT):
I see gerrit top f1e2b40e912b0b07f991e7ab8dbade6db37fa763f1e2b40e912b0b07f991e7ab8dbade6db37fa763 that works for me

MHBauer (Wed, 19 Sep 2018 06:47:19 GMT):
`git review -d 26323 `

MHBauer (Wed, 19 Sep 2018 06:47:20 GMT):
that one

MHBauer (Thu, 20 Sep 2018 01:13:54 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=E4CEyg36acwFdjrQZ) @guoger q is for quoted

MHBauer (Thu, 20 Sep 2018 01:14:33 GMT):
so what will get printed is `need 2 params, got "4"`

MHBauer (Thu, 20 Sep 2018 01:15:02 GMT):
so, probably not too relevant in this case, but more useful for errs

guoger (Thu, 20 Sep 2018 04:27:04 GMT):
oh, interesting.. i don't that.. but shouldn't quoted be more suitable for string-like msg? anyway, all lgtm

guoger (Thu, 20 Sep 2018 04:27:04 GMT):
oh, interesting.. i don't know that.. but shouldn't quoted be more suitable for string-like msg? anyway, all lgtm

MHBauer (Thu, 20 Sep 2018 05:18:11 GMT):
agree, agree. sort of a habit I've gotten into. usually makes the arguments "stand out" . more sure about what was "added in" rather than part of the original message text.

MHBauer (Thu, 20 Sep 2018 05:18:29 GMT):
keep an eye out.

guoger (Thu, 20 Sep 2018 05:53:14 GMT):
you have me looked up "keep an eye out" :)

MHBauer (Fri, 21 Sep 2018 02:17:14 GMT):
sorry, idioms, I love them.

MHBauer (Fri, 21 Sep 2018 02:17:50 GMT):
In the future, I may do similar things. Please notify me if this happens again. It is good to talk and think about.

guoger (Fri, 21 Sep 2018 02:30:30 GMT):
i mostly want to thank you for expanding me vocabulary :)

MHBauer (Fri, 21 Sep 2018 03:05:48 GMT):
Oh sure. Ask @Swetha, she'll tell you all about my words. I have the best words.

MHBauer (Fri, 21 Sep 2018 03:07:16 GMT):
I think the idioms are probably the hardest thing about a language.

MHBauer (Fri, 21 Sep 2018 03:07:21 GMT):
Other than maybe puns.

MHBauer (Fri, 21 Sep 2018 03:10:52 GMT):
and yea, if I say something and it seems wrong, or I am not making sense, ask me to clarify.

raheelz (Mon, 24 Sep 2018 16:12:02 GMT):
Hi, had a question regarding setting up locally with docker containers. Would it be similar to setting up fabric locally, and then installing and instantiating the evm chaincode (evmcc) ? Next step, I am assuming would be setting up the proxy..

cbf (Mon, 24 Sep 2018 17:28:54 GMT):
@raheelz yep. See https://github.com/hyperledger/fabric-chaincode-evm#deploying-the-fabric-evm-chaincode

swetha (Mon, 24 Sep 2018 18:40:13 GMT):
@cbf, need another round of reviews for this patch: https://gerrit.hyperledger.org/r/#/c/26172/

cbf (Mon, 24 Sep 2018 19:44:19 GMT):
ok

swetha (Mon, 24 Sep 2018 21:51:46 GMT):
thanks!

cbf (Tue, 25 Sep 2018 11:48:42 GMT):
thank you!

zacpl (Fri, 28 Sep 2018 18:37:19 GMT):
Has joined the channel.

grice32 (Thu, 04 Oct 2018 17:35:19 GMT):
Has joined the channel.

Barry_CPF (Fri, 05 Oct 2018 16:10:26 GMT):
Has joined the channel.

swetha (Fri, 05 Oct 2018 22:47:46 GMT):
@cbf @guoger pushed up some commits with integration tests for web3 and fab3 (checking spec implementation). We need to update the pipeline job to have node and working out some tweaks in the tests so commits not quite ready for review

swetha (Sat, 06 Oct 2018 18:22:21 GMT):
@cbf & @guoger we need review on this https://gerrit.hyperledger.org/r/#/c/26827/ to get node installed before our integration tests

guoger (Mon, 08 Oct 2018 03:54:03 GMT):
@swetha do integration tests assume peer and orderer docker images to exist locally?

guoger (Mon, 08 Oct 2018 03:57:59 GMT):
and why does [this](https://gerrit.hyperledger.org/r/c/26829/) trigger an update of ginkgo deps?

guoger (Mon, 08 Oct 2018 04:29:29 GMT):
[this](https://jenkins.hyperledger.org/job/fabric-chaincode-evm-verify-master-x86_64/130/console) says `ginkgo` not found...

cbf (Mon, 08 Oct 2018 11:59:04 GMT):
@swetha @guoger https://gerrit.hyperledger.org/r/c/26827/ some comments

swetha (Mon, 08 Oct 2018 16:20:59 GMT):
@guoger it runs the peer and orderer from $GOPATH/src/github.com/hyperledger/fabric

swetha (Mon, 08 Oct 2018 16:21:38 GMT):
And still trying to figure out the way to trigger it properly. i think i need to manually add to the path

cbf (Mon, 08 Oct 2018 16:38:09 GMT):
add ginkgo to the path?

cbf (Mon, 08 Oct 2018 16:38:18 GMT):
@swetha ^

cbf (Mon, 08 Oct 2018 16:40:13 GMT):
if that's what you're trying to accomplish, see the integration-test target in fabric makefile and also the gotool.ginkgo target in the gotools.mk

cbf (Mon, 08 Oct 2018 16:40:52 GMT):
also we need to vendor the relevant version of ginkgo

guoger (Mon, 08 Oct 2018 17:04:16 GMT):
ahh, great. I wasn't sure how to add that :)

guoger (Mon, 08 Oct 2018 17:04:56 GMT):
@swetha not sure which message you were trying to address though...

cbf (Mon, 08 Oct 2018 17:56:02 GMT):
we should be getting binaries from Nexus from stable build

swetha (Mon, 08 Oct 2018 22:16:27 GMT):
Yup I did follow what fabric did, but i think this is running slightly differently than fabric is in jenkins which is causing an issue

swetha (Mon, 08 Oct 2018 22:16:37 GMT):
We are vendoring in the same version of ginkgo as fabric

swetha (Mon, 08 Oct 2018 22:17:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=8wRYwfaQiiwm2JMLe) @guoger That was related to ``` @swetha do integration tests assume peer and orderer docker images to exist locally? and why does this trigger an update of ginkgo deps? ```

swetha (Mon, 08 Oct 2018 22:17:37 GMT):
Though I think I misunderstood that last part

guoger (Tue, 09 Oct 2018 09:30:00 GMT):
@swetha ah, they are two different questions and you need to click into the hyperlink of [this](https://gerrit.hyperledger.org/r/c/26829/)

swetha (Tue, 09 Oct 2018 13:53:17 GMT):
It didn't trigger an update. that part of ginkgo wasn't vendored in because we dont use it for our tests (the actually ginkgo binary)

swetha (Tue, 09 Oct 2018 13:53:26 GMT):
so we need to add it in order for ci to install it

tahaf10 (Sat, 13 Oct 2018 07:06:37 GMT):
Has joined the channel.

SumanPapanaboina (Sun, 14 Oct 2018 15:36:44 GMT):
Has joined the channel.

fupeng (Mon, 15 Oct 2018 14:53:49 GMT):
Has joined the channel.

fupeng (Mon, 15 Oct 2018 14:54:33 GMT):
Does fabric-evm support events now?

cbf (Mon, 15 Oct 2018 15:21:37 GMT):
@swetha ?

guoger (Mon, 15 Oct 2018 15:41:58 GMT):
@fupeng if you are thinking of `events` in Ethereum term, meaning it can be indexed, which makes tx query faster, then *no*, it's not supported, because we need to change Fabric to make it work.

guoger (Mon, 15 Oct 2018 15:43:07 GMT):
if it's just to support notification, like other Fabric event, then the CR is in gerrit, not merged yet. It's done by a Hyperledger intern and we'll need to revive it.

fupeng (Mon, 15 Oct 2018 16:04:08 GMT):
thanks! I am using web3.js. Can I use something like var event = contract.allEvents() event.watch(...) ?

fupeng (Mon, 15 Oct 2018 16:18:40 GMT):
"Introduction of events in Smart Contracts" from "Future Work" part of Extend-Hyperledger-Fabric-to-Support-EVM-Contract-and-Web3-Toolings_Jiannan-Guo-_-Swetha-Repakula.pdf

fupeng (Mon, 15 Oct 2018 16:19:19 GMT):
Sorry for the confusion :slight_smile:

fupeng (Mon, 15 Oct 2018 16:27:39 GMT):
From FAB-8078, I found "Current Status: Working through final CR to add event support. Testing underway - deliver soon after v1.3"

swetha (Mon, 15 Oct 2018 16:33:36 GMT):
@fupeng We are currently working with the Hyperledger Intern to finish testing and fixing the CRs. I am not sure that the work being reviewed will allow for a generic watch yet. But I have to double check to make sure

fupeng (Mon, 15 Oct 2018 16:43:06 GMT):
Got it! Thanks a lot. Hope it is to release soon! :slight_smile:

swetha (Mon, 15 Oct 2018 16:48:37 GMT):
Np!

swetha (Mon, 15 Oct 2018 17:03:38 GMT):
@cbf & @guoger I think the node patch is ready for another round of reviews: https://gerrit.hyperledger.org/r/#/c/26827/

swetha (Mon, 15 Oct 2018 22:29:40 GMT):
@cbf, Sorry didn't see that you were debugging the ginkgo issue. I might have messed up the last build by pushing. I will stop looking into that issue

cbf (Mon, 15 Oct 2018 22:30:01 GMT):
I think I sorted things out

swetha (Mon, 15 Oct 2018 22:30:27 GMT):
oh cool

cbf (Mon, 15 Oct 2018 22:32:08 GMT):
the gotool.ginkgo target was never built - also there's no need to build into the .build which was not in the path anyway

cbf (Mon, 15 Oct 2018 22:33:48 GMT):
hmmm... now b0rked

swetha (Mon, 15 Oct 2018 22:45:10 GMT):
i think its the debug line `which ginkgo`

swetha (Mon, 15 Oct 2018 22:45:34 GMT):
wait nope that's not it

swetha (Tue, 16 Oct 2018 04:11:58 GMT):
@cbf I think i figured out why ginkgo isn't installing properly. Something isn't right about the files that are vendored in. I will keep digging

swetha (Tue, 16 Oct 2018 04:42:24 GMT):
ginkgo should be working in the latest patch

ibmamnt (Wed, 17 Oct 2018 07:59:45 GMT):
Has joined the channel.

KOttoni (Wed, 17 Oct 2018 19:53:07 GMT):
Has joined the channel.

KOttoni (Wed, 17 Oct 2018 19:53:12 GMT):
Hello--Where in the documentation or elsewhere is there information regarding Ethereum compatibility (tx, tokens) in the 1.3 release? I did a search and couldn't find anything. Thanks!

swetha (Wed, 17 Oct 2018 20:58:56 GMT):
@KOttoni In terms of how we to use ethereum the we have an example tutorial that goes through that. In terms of just compatibility we have a design document that covers some of the limitations: https://docs.google.com/document/d/1xZfdtFiIFvHI7UZAze2xbm5hhgaDHGRBMusozKfpOck/edit?usp=sharing

swetha (Wed, 17 Oct 2018 20:58:56 GMT):
@KOttoni In terms of how we to use ethereum the we have an example tutorial that goes through that:https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md. In terms of just compatibility we have a design document that covers some of the limitations: https://docs.google.com/document/d/1xZfdtFiIFvHI7UZAze2xbm5hhgaDHGRBMusozKfpOck/edit?usp=sharing

swetha (Wed, 17 Oct 2018 21:00:49 GMT):
We are not introducing tokens as part of this work. In terms of transactions, we are using the Burrow EVM (0.18.0). We are still working on getting smart contract events, so that is also a limitation

cbf (Thu, 18 Oct 2018 14:55:51 GMT):
@KOttoni while we aren't introducing tokens, you can deploy an ERC20 or other standard contract to create tokens

cbf (Thu, 18 Oct 2018 14:56:36 GMT):
the tx format is consistent with web3

AndrewNRise (Fri, 19 Oct 2018 08:19:40 GMT):
Has joined the channel.

devlintrace (Fri, 19 Oct 2018 17:32:00 GMT):
Has joined the channel.

raheelz (Fri, 19 Oct 2018 19:59:59 GMT):
Hi, I am working on this project for a code pattern on loyalty points use case with fabric-evm: https://github.com/raheelzubairy/loyalty-points-evm-fabric. I would appreciate any feedback or if anything stands out. I used the example tutorial for the setup of Fabric-EVM. And truly liked the idea of creating a smart contract in Solidity and using web3 for the application, with the deployment on Fabric. Again, please let me know any concerns or feedback. -thanks

guoger (Sat, 20 Oct 2018 06:50:01 GMT):
wow, nice...

swetha (Mon, 22 Oct 2018 09:52:58 GMT):
@raheelz That's awesome.Will let you know if we have any feedback!

grapebaba (Wed, 24 Oct 2018 00:59:05 GMT):
Has joined the channel.

bobsummerwill (Thu, 25 Oct 2018 06:58:47 GMT):
Has joined the channel.

swetha (Thu, 25 Oct 2018 17:49:08 GMT):
@cbf & @guoger I think this patch is ready to be reviewed: https://gerrit.hyperledger.org/r/#/c/26241/

htinshar (Mon, 29 Oct 2018 08:50:49 GMT):
Has joined the channel.

kaustavha (Wed, 31 Oct 2018 01:46:48 GMT):
Has joined the channel.

kaustavha (Wed, 31 Oct 2018 02:03:53 GMT):
Hi there, is there a way to get the private key to the ethereum address created via instantiating the chaincode and accessible via the fabproxy?

kaustavha (Wed, 31 Oct 2018 02:04:16 GMT):
(i used raheelz repo readme)

guoger (Wed, 31 Oct 2018 05:23:12 GMT):
@kaustavha sorry i don't understand you question... are you trying to get the priv key that is used to instantiate evm chaincode?

kaustavha (Wed, 31 Oct 2018 08:13:35 GMT):
i am trying to get the priv key behind the default account given to us. and yes i do believe its used to instantiate evm contracts, its an ethereum account on the evm, but not to instantiate evm chaincode

kaustavha (Wed, 31 Oct 2018 08:14:18 GMT):
https://github.com/IBM/loyalty-points-evm-fabric

kaustavha (Wed, 31 Oct 2018 08:14:36 GMT):
if you look at that readme, im trying to get the privkey behind the web3.eth.accounts[0] entity in step 3

guoger (Wed, 31 Oct 2018 08:39:21 GMT):
@kaustavha ah, in that case, it's the priv key you start `fab3`(fabproxy) with. what `evmcc` does is to `stub.GetCreator()` and convert it to address.

sreeharsha_katta (Wed, 31 Oct 2018 13:05:38 GMT):
Has joined the channel.

kaustavha (Wed, 31 Oct 2018 13:37:08 GMT):
Ah okay so perhaps i can hook into the fab proxy and get it to spit out the privkey then.

kaustavha (Wed, 31 Oct 2018 13:39:41 GMT):
So im trying to run the simpleStorage contract but i keep getting errors after deploying the contract ``` myContract.set(10) Error: Failed to execute transaction: Transaction processing for endorser [localhost:7051]: Chaincode status Code: (500) UNKNOWN. Description: failed to deploy code: call error: invalid opcode 4D697373696E67206F70636F64652030783437 ```

kaustavha (Wed, 31 Oct 2018 13:40:03 GMT):
``` myContract.get() Error: Failed to query the ledger: ChaincodeID and Fcn are required ```

swetha (Wed, 31 Oct 2018 22:43:04 GMT):
@kaustavha I need a little more information about the setup. Those errors look like fab3 isn't properly configured with your network

swetha (Wed, 31 Oct 2018 22:44:44 GMT):
Also the account address that you get that you need for web3, is not the private key. It is an address that is generated from a user's public key. You need it because web3 requires it to be set, but in terms of fabric it looks at the public key of the signed transaction and doesn't pay attention to the converted account address.

swetha (Wed, 31 Oct 2018 22:45:11 GMT):
Is this the tutorial you are looking at https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md ?

swetha (Wed, 31 Oct 2018 22:45:11 GMT):
If you are testing the simple storage contract this might be a better tutorial: https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md ?

swetha (Wed, 31 Oct 2018 22:47:45 GMT):
Also what did you need the private key for? The account address that gets spit out is mostly needed to be able to use web3. The address as Jay mentions is just a translation of a person's public key

swetha (Wed, 31 Oct 2018 22:49:30 GMT):
The private key should be in your generated certificates for the user you have specified for fab3 (fabproxy)

MHBauer (Wed, 31 Oct 2018 23:35:01 GMT):
@cbf @guoger , https://gerrit.hyperledger.org/r/#/c/26323/ has gotten a couple rounds of review from @swetha , and should be close.

MHBauer (Wed, 31 Oct 2018 23:35:33 GMT):
this is the implementaiton of I think the last function necessary in the json-rpc for remix to work as far as I've tested.

guoger (Thu, 01 Nov 2018 03:30:28 GMT):
great, i'll take a look today

guoger (Thu, 01 Nov 2018 03:30:31 GMT):
btw, https://www.the-blockchain.com/2018/10/28/ethereum-now-on-hyperledger-fabric/

guoger (Thu, 01 Nov 2018 03:31:08 GMT):
we are reported :) also, folks in china are chatting about this in wechat groups and excited to try

htinshar (Thu, 01 Nov 2018 05:16:07 GMT):
When I pass long byte code of the smart contract to this command, `peer chaincode invoke -n -C hivelocitychannel -c '{"Args":["0000000000000000000000000000000000000000","''"]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/hivelocity.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem `, I've got this error `Error: endorsement failure during invoke. response: status:500 message:"failed to deploy code: call error: REVERT not yet fully implemented`. But when I try to pass short byte code, the command is pass and contract is correctly install. I would like to know, how can I pass long byte code to that command.

htinshar (Thu, 01 Nov 2018 05:16:07 GMT):
When I pass long byte code of the smart contract to this command, `peer chaincode invoke -n -C hivelocitychannel -c '{"Args":["0000000000000000000000000000000000000000","''"]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/hivelocity.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem `, I have got this error `Error: endorsement failure during invoke. response: status:500 message:"failed to deploy code: call error: REVERT not yet fully implemented`. But when I try to pass short byte code, the command is pass and contract is correctly install. I would like to know, how can I pass long byte code to that command.

htinshar (Thu, 01 Nov 2018 05:16:07 GMT):
When I pass long byte code of the smart contract to this command, ```peer chaincode invoke -n -C hivelocitychannel -c '{"Args":["0000000000000000000000000000000000000000","''"]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/hivelocity.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem ```, I have got this error `Error: endorsement failure during invoke. response: status:500 message:"failed to deploy code: call error: REVERT not yet fully implemented`. But when I try to pass short byte code, the command is pass and contract is correctly install. I would like to know, how can I pass long byte code to that command.

htinshar (Thu, 01 Nov 2018 05:16:07 GMT):
When I pass long byte code of the smart contract to this command, ```peer chaincode invoke -n -C -c '{"Args":["0000000000000000000000000000000000000000","''"]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/hivelocity.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem ```, I have got this error `Error: endorsement failure during invoke. response: status:500 message:"failed to deploy code: call error: REVERT not yet fully implemented`. But when I try to pass short byte code, the command is pass and contract is correctly install. I would like to know, how can I pass long byte code to that command.

guoger (Thu, 01 Nov 2018 05:18:50 GMT):
i don't think there's a problem with the length of bytecode. i suspect the bytecode is erroneous... make sure you are installing compiled bytecode, instead of runtime bytecode

guoger (Thu, 01 Nov 2018 05:18:50 GMT):
i don't think this is a problem with the length of bytecode. i suspect the bytecode is erroneous... make sure you are installing compiled bytecode, instead of runtime bytecode

htinshar (Thu, 01 Nov 2018 05:27:39 GMT):
@guoger This is my test contract `https://ropsten.etherscan.io/address/0x85fd9925754267054c11d3ba7cae31167fde4a45`, I also try with copy the source code to `remix` and get the compiled bytecode from `remix`. And pass that bytecode to above command, but the error is still happen.

htinshar (Thu, 01 Nov 2018 10:10:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=NacdxATbMweTZqxRR) @guoger I found the bugs, the error is because of I use `oraclize` service in my smart contract.

swetha (Thu, 01 Nov 2018 16:56:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=prKd3xJ7AB9W8LuPs) @guoger Seems to be a lot of articles coming up about the work!

MHBauer (Thu, 01 Nov 2018 17:45:50 GMT):
wowee

MHBauer (Thu, 01 Nov 2018 17:46:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=prKd3xJ7AB9W8LuPs) @guoger super duper

MHBauer (Thu, 01 Nov 2018 17:47:03 GMT):
I should pet back on the FRENCH + CHINESE language lessons.

MHBauer (Thu, 01 Nov 2018 17:47:12 GMT):
and typing.

nrohith (Fri, 02 Nov 2018 20:46:55 GMT):
Has joined the channel.

carlosfaria (Sat, 03 Nov 2018 00:54:03 GMT):
Has joined the channel.

guoger (Sat, 03 Nov 2018 01:23:50 GMT):
@MHBauer replied in [your CR](https://gerrit.hyperledger.org/r/c/26323/), LGTM, +2'ed.

swetha (Mon, 05 Nov 2018 19:11:20 GMT):
and with that i believe we have remix support!

cbf (Tue, 06 Nov 2018 07:28:29 GMT):
@MHBauer I tweaked your CR to get it to pass CI https://gerrit.hyperledger.org/r/c/27295/

cbf (Tue, 06 Nov 2018 07:28:50 GMT):
@swetha awesome!

yoheiueda (Wed, 07 Nov 2018 01:17:22 GMT):
Has joined the channel.

enriquebusti (Wed, 07 Nov 2018 12:01:14 GMT):
Has joined the channel.

matthewphamilton (Wed, 07 Nov 2018 14:28:00 GMT):
Has joined the channel.

matthewphamilton (Wed, 07 Nov 2018 14:30:04 GMT):
Lots of articles about this work, congrats to everyone. Where can I find documentation to learn more?

swetha (Wed, 07 Nov 2018 18:10:25 GMT):
Our tutorial/doc at the moment is here: https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md

swetha (Wed, 07 Nov 2018 18:10:25 GMT):
@matthewphamilton Our tutorial/doc at the moment is here: https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md

matthewphamilton (Wed, 07 Nov 2018 19:22:05 GMT):
ty @swetha

swetha (Wed, 07 Nov 2018 19:22:14 GMT):
Np!

mkhraisha (Wed, 07 Nov 2018 21:46:41 GMT):
Has joined the channel.

MHBauer (Thu, 08 Nov 2018 01:26:57 GMT):
@cbf thanks for looking at https://gerrit.hyperledger.org/r/27295

VenkatThota (Thu, 08 Nov 2018 11:10:50 GMT):
Has joined the channel.

Afe95 (Sat, 10 Nov 2018 14:38:43 GMT):
Has joined the channel.

swetha (Mon, 12 Nov 2018 17:18:13 GMT):
@cbf @guoger @MHBauer https://gerrit.hyperledger.org/r/#/c/26824/ this is finally ready for review

mkhraisha (Mon, 12 Nov 2018 20:46:32 GMT):
Hi, is there any way i can currently see what the transaction did? so if i make a call on a smart contract in the EVMCC to mint 5 tokens to address 1, where would i be able to look for that information?

swetha (Mon, 12 Nov 2018 21:54:55 GMT):
@mkhraisha Are you wanting to see the transaction inputs? You can query the fabric ledger for the transaction using the Fabric txID or you can pass in the txID to getTransactionByHash using Fab3 and web3. The EVMCC does not have any tokens associated with it and accounts will not have any balance either, in case that was what you were asking in the second part of your question. The "account" is generated on the fly from the user's public key but not stored anywhere.

rameshthoomu (Tue, 13 Nov 2018 00:55:05 GMT):
Has joined the channel.

rameshthoomu (Tue, 13 Nov 2018 01:05:50 GMT):
@swetha ^^

swetha (Tue, 13 Nov 2018 01:08:37 GMT):
Oh great! thanks @rameshthoomu !

compleatang (Tue, 13 Nov 2018 04:05:16 GMT):
That's a sad bot right there! ;-)

mkhraisha (Tue, 13 Nov 2018 16:04:36 GMT):
@swetha When i query the ledger using a fabric txID i get a txHash, a blockHash, a blockNumber, contractAddress ,gasUsed,cumGasUsed and transactionIndex. I would like to know what function was called on the contract. for example in a normal Ethereum TX theres a logs object that in an ERC20 transfer would include from/to/amount etc. If i implement that exact same erc20 in the evmcc how am i able to know my tx details

swetha (Tue, 13 Nov 2018 18:35:35 GMT):
@mkhraisha How are you querying the ledger?

mkhraisha (Tue, 13 Nov 2018 18:38:31 GMT):
from fab3 for example fab3.eth.getTransactionReceipt(tx);

mkhraisha (Tue, 13 Nov 2018 18:38:31 GMT):
@swetha from fab3 for example fab3.eth.getTransactionReceipt(tx);

swetha (Tue, 13 Nov 2018 18:39:48 GMT):
do `fab3.eth.getTransaction(tx)`

swetha (Tue, 13 Nov 2018 18:40:24 GMT):
that should give you some more information

swetha (Tue, 13 Nov 2018 18:42:28 GMT):
We also don't support logs or events at the moment

mkhraisha (Tue, 13 Nov 2018 18:43:15 GMT):
do you support a way to get all of my transaction history

swetha (Tue, 13 Nov 2018 18:44:20 GMT):
No, we don't have any filtering implemented yet. You have manually go through the blocks

eetti (Tue, 13 Nov 2018 18:45:56 GMT):
Has joined the channel.

mkhraisha (Tue, 13 Nov 2018 18:46:32 GMT):
ok thank you

mkhraisha (Tue, 13 Nov 2018 19:13:14 GMT):
@swetha i have attempted to do fab3.eth.getTransaction(tx) however it tells me that it can't find method "eth.getTransactionByHash"

swetha (Tue, 13 Nov 2018 20:08:31 GMT):
@mkhraisha That was a recent change that was added, so try pulling on master and rebuilding fab3

swetha (Tue, 13 Nov 2018 20:13:24 GMT):
@cbf & @guoger, this is ready for review: https://gerrit.hyperledger.org/r/#/c/27295/

guoger (Wed, 14 Nov 2018 01:41:02 GMT):
merged

swetha (Wed, 14 Nov 2018 04:39:27 GMT):
got a more patches to be reviewed: https://gerrit.hyperledger.org/r/#/c/27515/

swetha (Wed, 14 Nov 2018 04:39:27 GMT):
got more patches to be reviewed: https://gerrit.hyperledger.org/r/#/c/27515/

htinshar (Wed, 14 Nov 2018 05:06:59 GMT):
smart contract can call function from another contract in fabric-evm? I have smart contract A and B and both contract are installed under one evm chaincode. Installation and invoke single function is fine. But when I invoke the function from contract A which is calling contract B function, It show `Contract does not have permission to call` error. I'm also pass contact B address in constructor argument when I deploy with web3 js SDK. This is sample test contract ``` contract A { ContractBInterface contractB; constructor(ContractBInterface _stateHolder) public { contractB = _stateHolder; } function getFee() public view returns(uint256) { uint256f fee = contractB.getFee(); return fee; } } ```

hyper-sunder (Wed, 14 Nov 2018 10:25:44 GMT):
Has joined the channel.

hyper-sunder (Wed, 14 Nov 2018 10:27:31 GMT):
@swetha I have recently watched the video which explains about `EVM with Fabric`. Can we do `value transaction` using `EVM`? If yes, where does actually does? Inside the Hyperledger Fabric or Etherum Network?

hyper-sunder (Wed, 14 Nov 2018 10:31:01 GMT):
https://www.youtube.com/watch?v=Rr1Qi-n8vag => Explained well.

MuthuT (Wed, 14 Nov 2018 14:32:34 GMT):
Has joined the channel.

cbf (Wed, 14 Nov 2018 15:08:50 GMT):
@hyper-sunder not clear what you mean by a value transaction. Do you mean can you transact token ownership? To be clear, the EVM in the fabric-chaincode-evm is completely independent of the Ethereum network. We don't have Ether, and we don't require gas for smart contract operations. You can deploy an Ethereum smart contract written in Solidity, Vyper or any other valid DSL that can be compiled into EVM bytecode. e.g. you could deploy an ERC20 token contract and leverage it to manage ownership and transfers of a token - where that token exists within the context of the Fabric network in which it was initially created.

swetha (Wed, 14 Nov 2018 16:55:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=HgKmxmRJL3asRKZFQ) @htinshar @htinshar I am not sure why that error occurred. Is it possible to send me the two contracts you used for me to investigate?

swetha (Wed, 14 Nov 2018 16:55:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=HgKmxmRJL3asRKZFQ) @htinshar I am not sure why that error occurred. Is it possible to send me the two contracts you used for me to investigate?

hyper-sunder (Wed, 14 Nov 2018 17:06:21 GMT):
@cbf thanks for the reply. The `value transaction` means, transferring `Ether` from one account to another.

hyper-sunder (Wed, 14 Nov 2018 17:11:07 GMT):
@cbf So, EVM is used to run `Ethereum Smart Contract` written Solidity, Vyper or any other valid DSL in `Fabric` without refactoring it? Its not to do with `Ether` coin or token. Am I correct? Kindly correct me if I am wrong

swetha (Wed, 14 Nov 2018 17:14:28 GMT):
@hyper-sunder yes you are correct. If it can be compiled into EVM bytecode it should be able to run in the EVM in fabric. However as Chris mentioned we do not support Ether, value transactions, or any other tokens.

hyper-sunder (Wed, 14 Nov 2018 17:15:36 GMT):
@swetha Thanks a lot :)

hyper-sunder (Wed, 14 Nov 2018 17:15:48 GMT):
Is there any roadmap for the same?

swetha (Wed, 14 Nov 2018 17:16:12 GMT):
For tokens, no we don't have any plan for adding them as part of the EVM work

hyper-sunder (Wed, 14 Nov 2018 17:20:15 GMT):
@swetha fine. For instance, if a `Ethereum Smart Contract` involves some kind of amount transaction and I convert it into bytecode and install install it in `fabric-channel`. In that case how does EVM handles the `amount transfer` part of code?

swetha (Wed, 14 Nov 2018 17:23:11 GMT):
The asset that is being transferred would have to be part of the smart contract. If you do amount transfer in which you are transferring ether from one account to another, that will fail. We don't store user accounts as we don't need to keep track of balances

hyper-sunder (Wed, 14 Nov 2018 17:24:34 GMT):
@swetha and @cbf thanks a lot for clarification and making me to understand

swetha (Wed, 14 Nov 2018 17:24:44 GMT):
Np!

htinshar (Thu, 15 Nov 2018 04:12:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=oRJbc84Rs8Kn5e9N6) @swetha @swetha yes, I will send you my test contract address in etherscan. This is contract A-token contract(https://ropsten.etherscan.io/address/0x380e270dd784ad78bffe868739312dc316471463), This is contract B(https://ropsten.etherscan.io/address/0x3df6f9f4bac332a533b8faa419800aadbeedd711#code)

htinshar (Thu, 15 Nov 2018 04:12:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=oRJbc84Rs8Kn5e9N6) @swetha yes, I will send you my test contract address in etherscan. This is contract A-token contract(https://ropsten.etherscan.io/address/0x380e270dd784ad78bffe868739312dc316471463), This is contract B(https://ropsten.etherscan.io/address/0x3df6f9f4bac332a533b8faa419800aadbeedd711#code)

knagware9 (Thu, 15 Nov 2018 11:03:17 GMT):
@swetha I tried to setup EVM smart contract on fabric and able to succefully deploy and invoke smart contract but while using fabproxy not able to get contract address during contract deployment ,.,.where we can check the logs ..please find the error

knagware9 (Thu, 15 Nov 2018 11:03:47 GMT):

Screenshot from 2018-11-15 16-33-30.png

swetha (Thu, 15 Nov 2018 18:32:38 GMT):
@knagware9 when you deploy the contract only the transaction hash will be filled in. you get the contract address by getting the transaction receipt for the deployment.

swetha (Thu, 15 Nov 2018 19:22:45 GMT):
@htinshar When you say contract A what is the actual token you have deployed and how are you initializing the balances?

htinshar (Fri, 16 Nov 2018 02:16:46 GMT):
@swetha when deploy token contract(A), initial token supply is already set up. You might be notice at `INITIAL_SUPPLY` value and set that value to owner `balances[msg.sender] = INITIAL_SUPPLY`. In that contract when I remove line `349 to 352` (which is calling function from another contract), I can invoke transfer function from `web3` with `fabric proxy`. And also, before migrating to fabric, every function can invoke when I test that contracts with native evm and `web3` sdk.

htinshar (Fri, 16 Nov 2018 02:16:46 GMT):
@swetha Thanks for your reply. When deploy token contract(A), initial token supply is already set up. You might be notice at `INITIAL_SUPPLY` value and set that value to owner `balances[msg.sender] = INITIAL_SUPPLY`. And actual token is custom token which is similar like this contract `https://www.ethereum.org/token`. But I was calling function from another contract in my custom token contract. In my contract when I remove line `349 to 352` (which is calling function from another contract), I can invoke transfer function from `web3` with `fabric proxy`. And also, before migrating to fabric, every function can invoke when I test that contracts with native evm and `web3` sdk. Do you have any example resources for testing fabric evmcc with two smart contract which is calling function through interface?

bairathirahul (Fri, 16 Nov 2018 03:43:31 GMT):
Has joined the channel.

knagware9 (Fri, 16 Nov 2018 05:00:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=Se5GqcYMaADHYbLeK) @swetha How I can get the transaction receipt ,,we need contract address for next steps

htinshar (Fri, 16 Nov 2018 05:12:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=nyb8hGJyyMbPL6wr3) @knagware9 @knagware9 after `deployedContract = SimpleStorage.new([], {data: simpleStorageBytecode}) `, you can get your contract address with this script `address = web3.eth.getTransactionReceipt(deployedContract.transactionHash).contractAddress`(small letter `C` in `contractAddress`)

htinshar (Fri, 16 Nov 2018 05:12:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=nyb8hGJyyMbPL6wr3) @knagware9 after `deployedContract = SimpleStorage.new([], {data: simpleStorageBytecode}) `, you can get your contract address with this script `address = web3.eth.getTransactionReceipt(deployedContract.transactionHash).contractAddress`(small letter `C` in `contractAddress`)

knagware9 (Fri, 16 Nov 2018 05:25:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=g3KJxB8o5H224sEpW) @htinshar Thanks it works...actually in the instructions its Capital C https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md

knagware9 (Fri, 16 Nov 2018 07:31:48 GMT):
@swetha @htinshar I tried to setup https://github.com/IBM/vote-hyperledger-ethereum

knagware9 (Fri, 16 Nov 2018 07:32:11 GMT):
everyting works fine but during Vote .its giving error

knagware9 (Fri, 16 Nov 2018 07:32:22 GMT):
xample app listening on port 3000! Error: Failed to query the ledger: Transaction processing for endorser [localhost:7051]: Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: call error: REVERT not yet fully implemented at Object.InvalidResponse (/home/kamlesh/work/src/github.com/hyperledger/web3-fabric-voting-dapp/node_modules/web3/lib/web3/errors.js:38:16) at RequestManager.send (/home/kamlesh/work/src/github.com/hyperledger/web3-fabric-voting-dapp/node_modules/web3/lib/web3/requestmanager.js:61:22)

knagware9 (Fri, 16 Nov 2018 07:33:01 GMT):

Screenshot from 2018-11-16 13-02-44.png

htinshar (Fri, 16 Nov 2018 08:05:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=sEwNEvmNtpfWFqhxM) @knagware9 it is working, what value do you put in text box? In `server.js` line `25`, contract is deploy and init `candidateList` with this three value `yes, no, maybe`. So in UI textbox you should add `yes` or `no` or `maybe` with `small letter`.

knagware9 (Fri, 16 Nov 2018 08:20:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=eKeycmSDLpJFHG2ij) @htinshar Thanks...its taking only small letter like yes no

swetha (Fri, 16 Nov 2018 18:42:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=g3KJxB8o5H224sEpW) @htinshar Thanks for catching that. We will fix that in the readme

swetha (Fri, 16 Nov 2018 20:01:31 GMT):
@htinshar I am able to recreate the error and am looking into it

swetha (Fri, 16 Nov 2018 20:41:36 GMT):
I have created a jira ticket for the problem. Thanks for finding the bug: https://jira.hyperledger.org/browse/FAB-12903

swetha (Fri, 16 Nov 2018 20:41:36 GMT):
I have created a jira issue for the problem. Thanks for finding the bug: https://jira.hyperledger.org/browse/FAB-12903

swetha (Fri, 16 Nov 2018 20:49:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=pfSBTBmmc6Pthwp9A) @knagware9 Can you make an issue on that repo explaining the problem?

BellaAdams (Sat, 17 Nov 2018 00:45:56 GMT):
Has joined the channel.

swetha (Sat, 17 Nov 2018 01:40:04 GMT):
@cbf & @guoger this is ready for review: https://gerrit.hyperledger.org/r/#/c/27624/

htinshar (Mon, 19 Nov 2018 03:04:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=H9mTfwsWtXpNghSsn) @swetha Thank you

knagware9 (Mon, 19 Nov 2018 06:15:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=JojymQ8xDfjLtt9sL) @swetha Swetha .its not issue ..just small & capital letter issue

snowy13 (Mon, 19 Nov 2018 15:57:19 GMT):
Has joined the channel.

MHBauer (Mon, 19 Nov 2018 19:16:31 GMT):
@cbf @guoger @swetha https://gerrit.hyperledger.org/r/#/c/27497/ should be done. has testing now, full implemented the fuller transaction details.

swetha (Mon, 19 Nov 2018 19:28:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=7i5mtaoseaQqCjAqE) @knagware9 Even then, I would create a github issue explaining the confusion

huxiangdong (Tue, 20 Nov 2018 00:32:28 GMT):
Has joined the channel.

MHBauer (Tue, 20 Nov 2018 18:39:11 GMT):
anybody around know how to troubleshoot the integration tests? ``` [d][OrdererOrg.orderer] spawned /var/folders/km/qbjq1l4n0hng7j8jtc4kgjv00000gn/T/gexec_artifacts786700117/g779727705/orderer (pid: 8851) [e][OrdererOrg.orderer] 2018-11-20 10:34:40.822 PST [orderer.common.server] Main -> ERRO 001 failed to parse config: Error unmarshaling config into struct: 1 error(s) decoding: [e][OrdererOrg.orderer] [e][OrdererOrg.orderer] * 'General' has invalid keys: LogFormat, LogLevel ``` I don't know how to begin looking at this.

MHBauer (Tue, 20 Nov 2018 18:45:15 GMT):
works on the server, but I'd like to run it on my machine before pushing

MHBauer (Tue, 20 Nov 2018 19:31:40 GMT):
weird issue involving the gopath, I think.

MHBauer (Tue, 20 Nov 2018 19:32:16 GMT):
tests seem to use fabric in local gopath if it exists, but will download their own if it does not.

MHBauer (Tue, 20 Nov 2018 19:58:24 GMT):
and it downloads a new copy into the gopath, that's not good.

MHBauer (Tue, 20 Nov 2018 21:11:42 GMT):
pushed additional content to the existing web3 tests in https://gerrit.hyperledger.org/r/27682/

sanket1211 (Wed, 21 Nov 2018 06:12:10 GMT):
Has joined the channel.

engiwip (Wed, 21 Nov 2018 19:11:05 GMT):
Has joined the channel.

engiwip (Wed, 21 Nov 2018 19:11:09 GMT):
Hi

engiwip (Wed, 21 Nov 2018 19:12:00 GMT):
I ve had an issue on docker image

engiwip (Wed, 21 Nov 2018 19:12:38 GMT):
https://github.com/IBM/loyalty-points-evm-fabric/issues/6

engiwip (Wed, 21 Nov 2018 19:13:34 GMT):
any ideas ?

engiwip (Wed, 21 Nov 2018 19:22:17 GMT):
I m trying to install and Instantiate EVM chaincode from docker image

engiwip (Wed, 21 Nov 2018 19:47:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=uPtTMYpM9YgmFGgMF) @MHBauer Yup I think too . I've the same problem about export variable into gopath...

praveen.aloker (Thu, 22 Nov 2018 05:44:39 GMT):
Has joined the channel.

swetha (Mon, 26 Nov 2018 20:58:15 GMT):
@engiwip Are you still having a problem? Looking at the issue, it seems like the right permissions weren't set up. You would have to debug the first network to see why it wasn'

swetha (Mon, 26 Nov 2018 20:59:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=xvfvQJhBdxBoGNPoo) @engiwip Morgan was referring to integration tests in `fabric-chaincode-evm` repo. I don't think the gopath is the problem you are facing.

swetha (Mon, 26 Nov 2018 21:43:52 GMT):
@cbf & @guoger need another round of reviews on this: https://gerrit.hyperledger.org/r/#/c/27624/

guoger (Tue, 27 Nov 2018 08:46:57 GMT):
@swetha not sure i follow this sentence in commit msg: > Only return burrow contract accounts that have all the permissions for contract creation and contract invocation

cbf (Tue, 27 Nov 2018 12:32:44 GMT):
unclear to me why we want to give all permissions... can you please relate your reasoning here? @swetha thanks

swetha (Tue, 27 Nov 2018 17:43:43 GMT):
@cbf & @guoger the permissions here about creating a new contract from a contract and being able to call another contract from a contract

swetha (Tue, 27 Nov 2018 17:44:14 GMT):
We can set it to only allow the second one, and not allow contract creation from a contract

swetha (Tue, 27 Nov 2018 17:46:35 GMT):
but we do need to enable at least contracts calling contracts

MHBauer (Tue, 27 Nov 2018 19:16:14 GMT):
confused on the jira process. do we not touchclosed things?

MHBauer (Tue, 27 Nov 2018 19:17:10 GMT):
cause Iv'e got a couple against https://jira.hyperledger.org/browse/FAB-11081 but not sure if it should be against a *new* jira. hard to say when something like "integration tests" could ever be tocally complete.

swetha (Tue, 27 Nov 2018 20:14:08 GMT):
@MHBauer I would put your integration tests with the jira associated with the remix instructions

swetha (Tue, 27 Nov 2018 20:14:15 GMT):
that one isn't closed yet

swetha (Tue, 27 Nov 2018 20:14:29 GMT):
i was waiting for the corresponding integration tests to come in before closing that jira

cbf (Tue, 27 Nov 2018 20:42:15 GMT):
@swetha my preference would be to adhere to principe of least privilege

cbf (Tue, 27 Nov 2018 20:42:56 GMT):
@morgan, if a JIRA is closed prematurely then please reopen it. If you cannot, feel free to ping me

cbf (Tue, 27 Nov 2018 20:42:56 GMT):
@MHBauer , if a JIRA is closed prematurely then please reopen it. If you cannot, feel free to ping me

swetha (Tue, 27 Nov 2018 20:43:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=S9LmujPXT2F8hyFj8) @cbf I will update the patch to just allow contracts calling other contracts

cbf (Tue, 27 Nov 2018 20:43:59 GMT):
if you are going to use a single JIRA for multiple CRs, then suggest that you indicate this in the CR commit message

MHBauer (Tue, 27 Nov 2018 23:07:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=CX9zDabZNGFADH9xj) @cbf I think this adds more questions for me. I'm at "How do I JIRA" levels of understanding any interaction.

MHBauer (Tue, 27 Nov 2018 23:08:08 GMT):
@cbf @guoger https://gerrit.hyperledger.org/r/#/c/27652/ is ready

guoger (Wed, 28 Nov 2018 02:42:06 GMT):
@MHBauer is https://gerrit.hyperledger.org/r/c/27653/2 ready? i would like to get it in to have proper logging

swetha (Wed, 28 Nov 2018 03:16:27 GMT):
@guoger I was hoping we can hold off on that one until after https://gerrit.hyperledger.org/r/#/c/27747/ & https://gerrit.hyperledger.org/r/#/c/27624/

swetha (Wed, 28 Nov 2018 03:16:27 GMT):
@guoger I was hoping we can hold off on that one until after

swetha (Wed, 28 Nov 2018 03:17:07 GMT):
https://gerrit.hyperledger.org/r/#/c/27747/

swetha (Wed, 28 Nov 2018 03:17:17 GMT):
& https://gerrit.hyperledger.org/r/#/c/27321/

swetha (Wed, 28 Nov 2018 03:17:26 GMT):
the logging patch is easier to rebase than those two

guoger (Wed, 28 Nov 2018 03:17:37 GMT):
got it

swetha (Wed, 28 Nov 2018 03:18:20 GMT):
but otherwise i do believe the patch is ready to be reviewed

swetha (Wed, 28 Nov 2018 03:19:39 GMT):
also need another set of reviews on the permissions

swetha (Wed, 28 Nov 2018 03:19:39 GMT):
also need another set of reviews on the permissions patch

MHBauer (Wed, 28 Nov 2018 05:34:44 GMT):
for 27231 is there something I can do?

MHBauer (Wed, 28 Nov 2018 05:34:56 GMT):
I don't think logging should impact that too adly.

swetha (Wed, 28 Nov 2018 18:31:10 GMT):
If it seems like 27747 & 27321 will take too long to review then maybe, but rebasing is not going to be simple because the methods are being moved in 27747

mkhraisha (Wed, 28 Nov 2018 18:43:35 GMT):
@swetha when i call a chaincode query like ` peer chaincode query -n evmcc -C nm-channel -c '{"Args":["account"]}'` it creates a new docker image, is that expected behaviour?

swetha (Wed, 28 Nov 2018 18:50:34 GMT):
@mkhraisha If that is the first thing you are doing with the chaincode, yes it should be creating a new docker image. Fabric peers will create the chaincode container only when it is first invoked/queried

MHBauer (Wed, 28 Nov 2018 21:14:03 GMT):
@cbf whois ry and where do they live here on rocket chat?

MHBauer (Thu, 29 Nov 2018 18:44:56 GMT):
can I edit someone elses change or is that not possile?

swetha (Thu, 29 Nov 2018 20:31:44 GMT):
do you mean on gerrit?

MHBauer (Thu, 29 Nov 2018 23:08:03 GMT):
on gerrit, yes.

MHBauer (Thu, 29 Nov 2018 23:08:31 GMT):
wow, what builds the fabproxy binary? there's nothing in the makefile

MHBauer (Thu, 29 Nov 2018 23:09:27 GMT):
what is our release process?

swetha (Thu, 29 Nov 2018 23:16:08 GMT):
We try to go with the Fabric releases which is once a quarter. Fab3 is expected to be built manually by users at the moment

MHBauer (Thu, 29 Nov 2018 23:21:04 GMT):
which means what?

MHBauer (Thu, 29 Nov 2018 23:27:50 GMT):
git ignore looks really weird too.

swetha (Fri, 30 Nov 2018 00:33:48 GMT):
I think that is a remnant from when the evm was supposed to be a chaincode plugin. Most of that is probably unnecessary now

MHBauer (Fri, 30 Nov 2018 00:34:46 GMT):
well, I maed this https://gerrit.hyperledger.org/r/#/c/27827/ to make me happy.

swetha (Fri, 30 Nov 2018 01:00:21 GMT):
@MHBauer https://jira.hyperledger.org/browse/FAB-13065 for the ignored defers

swetha (Mon, 03 Dec 2018 02:09:46 GMT):
@cbf & @guoger we need reviews on the following: Contract to Contract invocations bug: https://gerrit.hyperledger.org/r/#/c/27624/ Refactor tx receipt in preparation for events code : https://gerrit.hyperledger.org/r/#/c/27747/ Events: https://gerrit.hyperledger.org/r/#/c/27321/ Build Cleanup: https://gerrit.hyperledger.org/r/#/c/27827/

dave.enyeart (Mon, 03 Dec 2018 06:35:37 GMT):
@cbf @swetha Will there be a v1.3 release for fabric-evm still? Or do you want to skip to v1.4 and release with the other components in mid-December?

dave.enyeart (Mon, 03 Dec 2018 06:35:50 GMT):
Please update the epic and story FixVersions accordingly

guoger (Mon, 03 Dec 2018 06:57:12 GMT):
@swetha pls remind me of the difference of `SentTx` and `Call`?

guoger (Mon, 03 Dec 2018 06:57:12 GMT):
@swetha pls remind me of the difference between `SentTx` and `Call`?

guoger (Mon, 03 Dec 2018 08:55:38 GMT):
@MHBauer have you sorted out your +2 privilege?

swetha (Mon, 03 Dec 2018 19:29:16 GMT):
@guoger Send transaction is submitting a transaction and call is a query

swetha (Mon, 03 Dec 2018 19:30:39 GMT):
@dave.enyeart I thought we already released fabric-evm as part of 1.3. There was an item that we pushed to 1.4. I will update the epic and fix versions.

MHBauer (Mon, 03 Dec 2018 20:48:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=u2x4DENDLkhHo6M7B) @guoger seems that way

swetha (Mon, 03 Dec 2018 21:09:34 GMT):
@MHBauer can you review https://gerrit.hyperledger.org/r/#/c/27624/ & https://gerrit.hyperledger.org/r/#/c/27747/?

dave.enyeart (Mon, 03 Dec 2018 23:26:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=ToQ5aXDMXBxyP5ST7) @swetha fabric-chaincode-evm has no tags, no releases, no release notes, that means it has not been released! @cbf expected to do this sometime after fabric v1.3 shipped.

swetha (Mon, 03 Dec 2018 23:28:30 GMT):
I will work with Chris to get that working. I will get back to you after that has all been resolved

dave.enyeart (Mon, 03 Dec 2018 23:28:40 GMT):
thanks!

MHBauer (Tue, 04 Dec 2018 00:48:55 GMT):
what's the release process? To do a relaese?

lehors (Tue, 04 Dec 2018 14:23:56 GMT):
Has joined the channel.

MHBauer (Tue, 04 Dec 2018 22:50:58 GMT):
some of the copied scripts we have store things into the fabric repo.

swetha (Tue, 04 Dec 2018 23:16:02 GMT):
Yea, as we use them we have been correcting them

MHBauer (Tue, 04 Dec 2018 23:17:43 GMT):
is there a reason we generate our own chaincode stub mock instead of using the one in fabric?

arjitkhullar (Wed, 05 Dec 2018 00:02:15 GMT):
Has joined the channel.

MHBauer (Wed, 05 Dec 2018 01:17:56 GMT):
why are we running both goimports and gofmt?

lehors (Wed, 05 Dec 2018 15:41:47 GMT):
hi guys, make integration-test fails for me when run against fabric master

lehors (Wed, 05 Dec 2018 15:42:02 GMT):
it works against fabric 1.3

lehors (Wed, 05 Dec 2018 15:42:15 GMT):
have you tested that?

guoger (Wed, 05 Dec 2018 15:44:37 GMT):
does it say something about logFormat/spec?

guoger (Wed, 05 Dec 2018 15:44:37 GMT):
@lehors does it say something about logFormat/spec?

guoger (Wed, 05 Dec 2018 15:45:59 GMT):
also we are preparing a release note saying it works against 1.3, not master

lehors (Wed, 05 Dec 2018 15:47:42 GMT):
yeah: [e][configtxgen-create-channel-tx] 2018-12-05 16:40:52.381 CET [common.tools.configtxgen] doOutputChannelCreateTx -> INFO 003 Writing new channel tx [d][OrdererOrg.orderer] spawned /var/folders/j1/4b3ygtd52x50rcq6czdsylwc0000gn/T/gexec_artifacts987406300/g063322320/orderer (pid: 78218) [e][OrdererOrg.orderer] 2018-12-05 16:40:52.495 CET [orderer.common.server] Main -> ERRO 001 failed to parse config: Error unmarshaling config into struct: 1 error(s) decoding: [e][OrdererOrg.orderer] [e][OrdererOrg.orderer] * 'General' has invalid keys: LogFormat, LogLevel ------------------------------ • Failure in Spec Setup (BeforeEach) [1.955 seconds]

lehors (Wed, 05 Dec 2018 15:48:33 GMT):
• Failure in Spec Setup (BeforeEach) [1.955 seconds] EndToEnd [BeforeEach] is able to run evm bytecode contracts /Users/lehors/Projects/Go/src/github.com/hyperledger/fabric-chaincode-evm/integration/e2e/e2e_test.go:77 Timed out after 1.003s. Expected <<-chan struct {} | len:0, cap:0>: 0xc000474540 to be closed /Users/lehors/Projects/Go/src/github.com/hyperledger/fabric-chaincode-evm/integration/e2e/e2e_test.go:63

guoger (Wed, 05 Dec 2018 16:29:10 GMT):
yeah.. that's expected :( , `orderer.yaml` for v1.3 orderer contained those keys, therefore incompatible with master orderer binary. the fabric we vendored is older than 1.3, however `nwo` integration tests builds fabric peer & orderer on `GOPATH`, which might be master depending on your local repo.

guoger (Wed, 05 Dec 2018 16:29:43 GMT):
but anyway, we should bump our Fabric to v1.3 at least, cc @swetha @MHBauer

lehors (Wed, 05 Dec 2018 16:57:15 GMT):
yeah, that's safe to do because I tested it against 1.3

MHBauer (Wed, 05 Dec 2018 20:26:50 GMT):
I couldn't build fabric 1.3.0, it was complaing about the javaenv image not existing

MHBauer (Thu, 06 Dec 2018 20:49:01 GMT):
@lehors we should be rebased on tag v1.3.0 very specificially and you should get a nice warning if things are out of sync for us

MHBauer (Tue, 11 Dec 2018 02:28:39 GMT):
fabproxy rpc needs to handle arrays of requests for batch mode.

MHBauer (Tue, 11 Dec 2018 05:12:01 GMT):
we'd have to edit gorilla to support it, or use the helpful link provided by golang godoc to find a replacement library. https://godoc.org/?q=json-rpc+2.0

lehors (Tue, 11 Dec 2018 13:20:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=abjymTzwM8Jgbt5pr) @MHBauer any idea when support for 1.4 might come?

lehors (Tue, 11 Dec 2018 13:20:52 GMT):
I'm actually curious to know what breaks

lehors (Tue, 11 Dec 2018 13:21:29 GMT):
one would think that 1.4 is backwards compatible with 1.3 and therefore things that work with 1.3 would still work with 1.4...

MHBauer (Tue, 11 Dec 2018 18:46:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=jEsLmpnLNXniZDQNe) @lehors not sure what this would mean, we were based on some version of fabric from July 10, which looks to be v1.1.1 maybe? There wasn't much difficulty at the code level. The main issue was the the integration test framework was changed and we coudl't find a specific image that caused it to blow up.

MHBauer (Tue, 11 Dec 2018 18:46:35 GMT):
I don't know what our policy is regarding following along.

MHBauer (Tue, 11 Dec 2018 18:46:58 GMT):
The sdk has it's own versioning scheme.

lehors (Tue, 11 Dec 2018 19:53:43 GMT):
@MHBauer are you saying the problem is within the SDK?

lehors (Tue, 11 Dec 2018 19:54:04 GMT):
I apologize if I appear clueless, it's because I am :-)

lehors (Tue, 11 Dec 2018 19:54:30 GMT):
the error I got when I tried left me puzzled

MHBauer (Tue, 11 Dec 2018 20:25:26 GMT):
Ah, we're talking about having master checked out and why doesn't that work. okay.

MHBauer (Tue, 11 Dec 2018 20:25:48 GMT):
I've not tried that. I will now

MHBauer (Tue, 11 Dec 2018 20:31:34 GMT):
ah, yes, jay has it up above. not something I would know about.

MHBauer (Tue, 11 Dec 2018 20:40:44 GMT):
so, https://github.com/hyperledger/fabric/commit/c209841938d56221b11a095537ebd14a77711fe4#diff-c3e0cc8bbd4e5ea2bf50b91fdff0a01f that broke it with root cause being the use of viperutil.EnhancedExactUnmarshal

MHBauer (Tue, 11 Dec 2018 20:40:55 GMT):
https://godoc.org/github.com/hyperledger/fabric/common/viperutil

MHBauer (Tue, 11 Dec 2018 20:41:15 GMT):
I can understand the idea, but that seems a bit strict to me.

MHBauer (Tue, 11 Dec 2018 20:41:45 GMT):
@lehors so, it's a breaking change because the code itself is exact about what it needs and will fail otherwise.

MHBauer (Tue, 11 Dec 2018 20:41:57 GMT):
and the templates in the old version have old fields

MHBauer (Tue, 11 Dec 2018 21:06:08 GMT):
If I change this sucker here https://github.com/hyperledger/fabric/blob/release-1.4/common/viperutil/config_util.go#L297 to false, it works fine. I'd prefer if it was "warn unused" or something, but I suppose nobody reads logs.

MHBauer (Tue, 11 Dec 2018 21:06:20 GMT):
so, that's the issue.

swetha (Wed, 12 Dec 2018 01:45:02 GMT):
@lehors I have to verify this, but I believe the evmcc should work with 1.4. Our integration tests just don't pass because we vendored in an older Fabric version for the integration test setup, so the configuration file causes an error when starting up the fabric network because of the change in the orderer keys

MHBauer (Wed, 12 Dec 2018 02:14:45 GMT):
it works fine, yes.

edwardlee (Thu, 13 Dec 2018 14:56:02 GMT):
Has joined the channel.

aviralwal (Mon, 17 Dec 2018 11:48:54 GMT):
Has joined the channel.

MHBauer (Tue, 18 Dec 2018 21:24:05 GMT):
marshalling test has been updated with the new fields from merging the events code https://gerrit.hyperledger.org/r/#/c/27764/

MHBauer (Tue, 18 Dec 2018 23:05:18 GMT):
what would we say to running integration in a container, maybe dind?

MHBauer (Wed, 19 Dec 2018 01:44:28 GMT):
Is there a way to force the chaincode to build?

MHBauer (Wed, 19 Dec 2018 01:44:53 GMT):
during the tests, it takes about 80sec a contriner to build it.

MHBauer (Wed, 19 Dec 2018 23:01:32 GMT):
https://gerrit.hyperledger.org/r/#/c/28201/ needs a +2 from someone else.

guoger (Thu, 20 Dec 2018 02:39:04 GMT):
+2 and submitted, but left some comments [here](https://gerrit.hyperledger.org/r/c/28201/2//COMMIT_MSG#11) and [here](https://gerrit.hyperledger.org/r/c/28201/2/fabproxy/cmd/main.go#96)

swetha (Thu, 20 Dec 2018 05:13:14 GMT):
made https://jira.hyperledger.org/browse/FAB-13385 & https://jira.hyperledger.org/browse/FAB-13384 to address those

lehors (Thu, 20 Dec 2018 15:00:54 GMT):
hi there, sadly the first Solidity contract I tried on my own failed to run due to a limitation in the burrow version that we currently use (0.18.0): "REVERT not yet fully implemented". It turns out that support for this was added in the very next version 0.19.0. Unfortunately switching version isn't trivial. There were some significant changes that impact our code. Has anyone looked into this?

lehors (Thu, 20 Dec 2018 15:02:19 GMT):
I saw we already have FAB-13102 for that matter

guoger (Thu, 20 Dec 2018 16:28:47 GMT):
yep, we were notified by burrow team a while ago when they implemented that opcode, and we also made an attempt to bump burrow version, but as you said, it requires significant changes on our side (especially they changed the account pkg). so we decided at that time to focus on finishing other stuff (fab3 etc) and defer this to post v0.1

MHBauer (Thu, 20 Dec 2018 20:53:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=4DNeAdKkFqka66tME) @swetha I love it when a plan comes together

lehors (Thu, 20 Dec 2018 21:10:08 GMT):
so, nobody asked me but I was curious and started looking into the upgrade of burrow...

lehors (Thu, 20 Dec 2018 21:10:36 GMT):
sadly, while I could get the code to compile against 0.19.0, the integration test fail

lehors (Thu, 20 Dec 2018 21:11:36 GMT):
I might dig in as time permit but with vacation starting it may not be for a while...

lehors (Thu, 20 Dec 2018 21:11:36 GMT):
I might dig in as time permits but with vacation starting it may not be for a while...

lehors (Thu, 20 Dec 2018 21:12:04 GMT):
note that upgrading to 0.19 is merely a first step

lehors (Thu, 20 Dec 2018 21:12:53 GMT):
this is still pretty far behind from the latest version but having looked at the changes it seemed prudent to take an incremental approach rather than trying to jump to the latest version

MHBauer (Thu, 20 Dec 2018 21:26:29 GMT):
yup, I think we're done for the release. last minute rebase of fabric, but this is definitely a thing to do later.

MHBauer (Fri, 21 Dec 2018 01:13:08 GMT):
so no 1.4 official until january

MHBauer (Fri, 21 Dec 2018 01:13:19 GMT):
rc2 based release tomorrow if we can swing it?

htinshar (Fri, 21 Dec 2018 09:05:07 GMT):
I was test contract to contract invoke with latest `evmcc` master branch with this two contracts. ``` contract ContractA { uint value; function setValue(uint _value) public returns (uint) { value = _value; return value; } function getValue() public view returns (uint) { return value; } } ``` ``` interface ContractAInterface { function setValue(uint _val) external returns (uint); function getValue() external view returns (uint); } contract ContractB { ContractAInterface contractA; constructor(address _contractAddr) public { contractA = ContractAInterface(_contractAddr); } function setValue(uint _value) public returns (uint result) { contractA.setValue(_value); return _value; } function getValue() public view returns (uint result) { return contractA.getValue(); } } ``` But when I invoke `setValue` and `getValue` function from `ContractB` , I got this error ` status Code: (500) UNKNOWN. Description: failed to execute contract: call error: RETURNDATASIZE not yet implemented`. `burrow` or `evmcc` won’t support contract to contract function calling?

guoger (Fri, 21 Dec 2018 09:13:32 GMT):
@htinshar hi, thanks for reporting this! contract-to-contract invocation is supported, but the opcode `RETURNDATASIZE` is not supported in the vendored version of burrow evm currently (*but it is supported now in newer burrow*). We will bump the burrow version once we release v0.1 (right after Fabric v1.4 is officially cut)

guoger (Fri, 21 Dec 2018 09:13:32 GMT):
@htinshar hi, thanks for reporting this! contract-to-contract invocation is supported, but the opcode `RETURNDATASIZE` is not supported in the vendored version of burrow evm currently ( *but it is supported now in newer burrow* ). We will bump the burrow version once we release v0.1 (right after Fabric v1.4 is officially cut)

htinshar (Fri, 21 Dec 2018 09:17:24 GMT):
@guoger I see, thanks for your reply. I can use this feature in evmcc v0.1.

htinshar (Fri, 21 Dec 2018 09:17:24 GMT):
@guoger I see, thanks for your reply. I can only use this feature in evmcc v0.1.

guoger (Fri, 21 Dec 2018 09:20:31 GMT):
sadly not `v0.1`. perhaps `v0.1.1`, cuz upgrading burrow dependency is actually a bit tricky since it introduces many changes, and we don't want to further delay the release as fabric v1.4 is very close to be released. But we did prioritize this and it shouldn't take too long after `v0.1`

guoger (Fri, 21 Dec 2018 09:20:51 GMT):
keep an eye on the repo :)

MHBauer (Fri, 21 Dec 2018 18:13:54 GMT):
@swetha @guoger something to add to release notes?

merq (Sat, 22 Dec 2018 03:44:46 GMT):
Has joined the channel.

swetha (Sun, 23 Dec 2018 19:13:53 GMT):
@lehors When we talked to Burrow team, they did properly implement the revert op code in a future release as you mention, however when you see that error it most likely means you ran into an error in the contract itself. The revert op code will give you a better error message though.

MuhammedHafil (Wed, 26 Dec 2018 06:56:59 GMT):
Has joined the channel.

MuhammedHafil (Wed, 26 Dec 2018 08:20:11 GMT):
https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/first-network-sdk-config.yaml is this config file used here is same as as the config we provide to node sdk? like this one? https://github.com/hyperledger/fabric-samples/blob/release-1.3/balance-transfer/artifacts/network-config.yaml

lehors (Wed, 26 Dec 2018 16:55:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=TfC9cGpn3h8QqrSFm) @swetha the contract is one of the samples available online and runs fine elsewhere

rohitsethi (Thu, 27 Dec 2018 11:35:13 GMT):
Has joined the channel.

rohitsethi (Thu, 27 Dec 2018 11:39:29 GMT):
trying to setup loyalty-points-evm-fabrics sample project from : https://github.com/IBM/loyalty-points-evm-fabric `````` on running the following command : `./byfn.sh up` ``` It gives following error in terminal ` ____ _____ _ ____ _____ / ___| |_ _| / \ | _ \ |_ _| \___ \ | | / _ \ | |_) | | | ___) | | | / ___ \ | _ < | | |____/ |_| /_/ \_\ |_| \_\ |_| Build your first network (BYFN) end-to-end test Channel name : mychannel Creating channel... + peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem + res=1 + set +x 2018-12-27 11:33:00.531 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized Error: got unexpected status: FORBIDDEN -- Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied !!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!! ========= ERROR !!! FAILED to execute End-2-End Scenario =========== ```` Test fails here``` ``` ``` ``` ``` ```

rohitsethi (Thu, 27 Dec 2018 11:39:29 GMT):
trying to setup loyalty-points-evm-fabrics sample project from : https://github.com/IBM/loyalty-points-evm-fabric `````` on running the following command : `./byfn.sh up` ``` ____ _____ _ ____ _____ / ___| |_ _| / \ | _ \ |_ _| \___ \ | | / _ \ | |_) | | | ___) | | | / ___ \ | _ < | | |____/ |_| /_/ \_\ |_| \_\ |_| Build your first network (BYFN) end-to-end test Channel name : mychannel Creating channel... + peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem + res=1 + set +x 2018-12-27 11:33:00.531 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized Error: got unexpected status: FORBIDDEN -- Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied !!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!! ========= ERROR !!! FAILED to execute End-2-End Scenario =========== ```` Test fails here

rohitsethi (Thu, 27 Dec 2018 11:39:29 GMT):
trying to setup loyalty-points-evm-fabrics sample project from : https://github.com/IBM/loyalty-points-evm-fabric ``` on running the following command : `./byfn.sh up` ``` `` ____ _____ _ ____ _____ / ___| |_ _| / \ | _ \ |_ _| \___ \ | | / _ \ | |_) | | | ___) | | | / ___ \ | _ < | | |____/ |_| /_/ \_\ |_| \_\ |_| Build your first network (BYFN) end-to-end test Channel name : mychannel Creating channel... + peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem + res=1 + set +x 2018-12-27 11:33:00.531 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized Error: got unexpected status: FORBIDDEN -- Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied !!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!! ========= ERROR !!! FAILED to execute End-2-End Scenario ===========````` ``` Test fails here

rohitsethi (Thu, 27 Dec 2018 11:39:29 GMT):
trying to setup loyalty-points-evm-fabrics sample project from : https://github.com/IBM/loyalty-points-evm-fabric ``` on running the command : `./byfn.sh up` ``` `` ____ _____ _ ____ _____ / ___| |_ _| / \ | _ \ |_ _| \___ \ | | / _ \ | |_) | | | ___) | | | / ___ \ | _ < | | |____/ |_| /_/ \_\ |_| \_\ |_| Build your first network (BYFN) end-to-end test Channel name : mychannel Creating channel... + peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem + res=1 + set +x 2018-12-27 11:33:00.531 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized Error: got unexpected status: FORBIDDEN -- Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied !!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!! ========= ERROR !!! FAILED to execute End-2-End Scenario ===========````` ``` Test fails here

rohitsethi (Thu, 27 Dec 2018 11:39:29 GMT):
trying to setup loyalty-points-evm-fabrics sample project from : https://github.com/IBM/loyalty-points-evm-fabric ``` on running the command : `./byfn.sh up` ``` ````` ` ____ _____ _ ____ _____ / ___| |_ _| / \ | _ \ |_ _| \___ \ | | / _ \ | |_) | | | ___) | | | / ___ \ | _ < | | |____/ |_| /_/ \_\ |_| \_\ |_| Build your first network (BYFN) end-to-end test Channel name : mychannel Creating channel... + peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem + res=1 + set +x 2018-12-27 11:33:00.531 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized Error: got unexpected status: FORBIDDEN -- Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied !!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!! ========= ERROR !!! FAILED to execute End-2-End Scenario ===========` ````` ``` Test fails here

rohitsethi (Thu, 27 Dec 2018 11:39:29 GMT):
trying to setup loyalty-points-evm-fabrics sample project from : https://github.com/IBM/loyalty-points-evm-fabric ``` on running the command : `./byfn.sh up` ``` ````` ` ____ _____ _ ____ _____ / ___| |_ _| / \ | _ \ |_ _| \___ \ | | / _ \ | |_) | | | ___) | | | / ___ \ | _ < | | |____/ |_| /_/ \_\ |_| \_\ |_| Build your first network (BYFN) end-to-end test Channel name : mychannel Creating channel... + peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem + res=1 + set +x 2018-12-27 11:33:00.531 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized Error: got unexpected status: FORBIDDEN -- Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied !!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!! ========= ERROR !!! FAILED to execute End-2-End Scenario ===========` ````` Test fails here

knagware9 (Thu, 27 Dec 2018 12:18:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=erxBbeTNH3vLp2RyA) @rohitsethi just do ./byfn.sh down first and remove docker network docker network prune and then try again..it will work

rohitsethi (Thu, 27 Dec 2018 12:33:15 GMT):
@knagware9 it worked. Thanks

MuhammedHafil (Fri, 28 Dec 2018 04:34:37 GMT):
hey Geeks, Can i ask a very noob question? where does actually our ethreum smart contract executes with fabric-evm tool? In our fabric blockchain or ethereum network? If it works only inside our fabric network all this effort done is only to execute solidity smart contract in fabric? and which state db it uses ?

MuhammedHafil (Fri, 28 Dec 2018 04:35:53 GMT):
@lehors @guoger @swetha , Please try to give an answer . Thanks

guoger (Fri, 28 Dec 2018 05:21:28 GMT):
@MuhammedHafil this is accurate > it works only inside our fabric network

guoger (Fri, 28 Dec 2018 05:21:51 GMT):
> which state db it uses It uses whichever your fabric chooses to use

guoger (Fri, 28 Dec 2018 05:22:20 GMT):
> only to execute solidity smart contract in fabric and JSON RPC based toolings, e.g. remix, truffle, etc

guoger (Fri, 28 Dec 2018 05:22:39 GMT):
and we plan to support some wallets as well

MuhammedHafil (Fri, 28 Dec 2018 05:41:59 GMT):
Thank you

rbailey (Mon, 31 Dec 2018 17:29:57 GMT):
Has joined the channel.

idavidasilva (Wed, 02 Jan 2019 14:44:21 GMT):
Has joined the channel.

xaviarias (Thu, 03 Jan 2019 11:02:59 GMT):
Has joined the channel.

KellyCooper (Thu, 03 Jan 2019 14:10:39 GMT):
The Learning Materials Development working group is in need of contributors for our 2019 objectives: edX Fabric update, edX Sawtooth update, edX Iroha tutorial. At this time, over 133,000 learners have participated in the edX courses. If you, or someone you know (university student, freelance developer, researcher, etc) is interested in contributing, please see the worksheet: 2019 Team and Individual/Small Group Objectives, Key Results, Participants and Tasks - https://goo.gl/1HzKaD The worksheet has two tabs, one for contributions to the group's 2019 OKRs, and a second that notes individual contributions. Feel free to message or reply with any questions. Thank you, Kelly

rameshthoomu (Fri, 04 Jan 2019 15:20:39 GMT):
@swetha Could you please review this change https://gerrit.hyperledger.org/r/#/c/28373

Shirikatsu (Fri, 04 Jan 2019 16:33:52 GMT):
Has joined the channel.

Shirikatsu (Fri, 04 Jan 2019 16:35:20 GMT):
Hi all, has anybody attempted to deploy this evm chaincode using the CLI here: https://github.com/securekey/fabric-examples/tree/master/fabric-cli

Shirikatsu (Fri, 04 Jan 2019 16:35:20 GMT):
Hi all, the current build on master seems to failing to instantiate. Any news?

silasdavis (Fri, 04 Jan 2019 17:12:02 GMT):
Hello fabric-evm... I wanted to share a project that @seanyoung has started that I think has a lot of potential to grow into something rather interesting. It is a solidity-to-LLVM compiler using modern compiler tooling to generate LLVM IR with an antlr grammar: https://github.com/seanyoung/solang. What we (Burrow) have in mind is using the LLVM WASM backend to create a migration path for existing solidity code and also thinking about WASM-EVM interop within Burrow that can bring with it a host of advantages. In the context of Hyperledger I would like to see WASM emerge as a cross-framework point of integration for different projects (and I know others would too). However this approach is interesting for chaincode written in any LLVM-supported backend architecture and has the advantage of running through sane, mature, modern compiling machinery.

cbf (Fri, 04 Jan 2019 18:32:04 GMT):
interesting! Thanks @silasdavis

MHBauer (Fri, 04 Jan 2019 18:56:25 GMT):
oh rust, nice.

MHBauer (Fri, 04 Jan 2019 18:57:25 GMT):
but nightly...

swetha (Fri, 04 Jan 2019 19:00:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=3tyBPfswAm7N7uDk2) @Shirikatsu Do you have any logs? We haven't had issues instantiating the code on master.

swetha (Fri, 04 Jan 2019 19:02:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=jBf96vK7porLPsQxK) @rameshthoomu taking a look now

MHBauer (Fri, 04 Jan 2019 19:02:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=jBf96vK7porLPsQxK) @rameshthoomu I reviewed

seanyoung (Sat, 05 Jan 2019 08:57:01 GMT):
@MHBauer obviously it would be nice to move to rust stable. Once box patterns end up in stable we can move to stable. https://doc.rust-lang.org/1.5.0/book/box-syntax-and-patterns.html

seanyoung (Sat, 05 Jan 2019 08:58:57 GMT):
In the AST we need to use box for recursion (e.g. Expression enum contains Expression). So we need box in this enum. But without the box pattern, how do we match these enums?

Shirikatsu (Mon, 07 Jan 2019 09:48:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=LNZSwviMvzCTPf6hi) @swetha @swetha Using `first-network` in the tutorials, installing evmcc: `peer chaincode install -n evmcc -l golang -v 0 -p github.com/hyperledger/fabric-chaincode-evm/evmcc` then instantiating: `peer chaincode instantiate -n evmcc -v 0 -C mychannel -c '{"Args":[]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem` fails with: `2019-01-04 16:50:09.370 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc 2019-01-04 16:50:09.371 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc Error: could not assemble transaction, err proposal response was not successful, error code 500, msg error starting container: error starting container: Failed to generate platform-specific docker build: Error returned from build: 2 "# github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/event chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/event/emitter.go:75:40: cannot use tags (type map[string]interface {}) as type pubsub.TagMap in argument to em.pubsubServer.PublishWithTags: map[string]interface {} does not implement pubsub.TagMap (missing Get method) # github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:47:50: pubKeyEd25519.Wrap undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PubKeyEd25519 has no field or method Wrap) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:52:28: pk.PubKey.Unwrap undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PubKey has no field or method Unwrap) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:78:2: not enough arguments to return chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:78:18: pk.PubKey.MarshalJSON undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PubKey has no field or method MarshalJSON) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:82:18: pk.PubKey.UnmarshalJSON undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PubKey has no field or method UnmarshalJSON) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:141:53: privKeyEd25519.Wrap undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PrivKeyEd25519 has no field or method Wrap) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:173:30: pk.PrivKey.Unwrap undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PrivKey has no field or method Unwrap) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:188:45: multiple-value pk.PrivKey.Sign() in single-value context chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:192:2: not enough arguments to return chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:192:19: pk.PrivKey.MarshalJSON undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PrivKey has no field or method MarshalJSON) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:192:2: too many errors " `

Shirikatsu (Mon, 07 Jan 2019 09:48:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=LNZSwviMvzCTPf6hi) @swetha @swetha Using `first-network` in the tutorials on v1.3, installing evmcc: `peer chaincode install -n evmcc -l golang -v 0 -p github.com/hyperledger/fabric-chaincode-evm/evmcc` then instantiating: `peer chaincode instantiate -n evmcc -v 0 -C mychannel -c '{"Args":[]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem` fails with: `2019-01-04 16:50:09.370 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc 2019-01-04 16:50:09.371 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc Error: could not assemble transaction, err proposal response was not successful, error code 500, msg error starting container: error starting container: Failed to generate platform-specific docker build: Error returned from build: 2 "# github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/event chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/event/emitter.go:75:40: cannot use tags (type map[string]interface {}) as type pubsub.TagMap in argument to em.pubsubServer.PublishWithTags: map[string]interface {} does not implement pubsub.TagMap (missing Get method) # github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:47:50: pubKeyEd25519.Wrap undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PubKeyEd25519 has no field or method Wrap) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:52:28: pk.PubKey.Unwrap undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PubKey has no field or method Unwrap) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:78:2: not enough arguments to return chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:78:18: pk.PubKey.MarshalJSON undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PubKey has no field or method MarshalJSON) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:82:18: pk.PubKey.UnmarshalJSON undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PubKey has no field or method UnmarshalJSON) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:141:53: privKeyEd25519.Wrap undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PrivKeyEd25519 has no field or method Wrap) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:173:30: pk.PrivKey.Unwrap undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PrivKey has no field or method Unwrap) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:188:45: multiple-value pk.PrivKey.Sign() in single-value context chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:192:2: not enough arguments to return chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:192:19: pk.PrivKey.MarshalJSON undefined (type "github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/tendermint/go-crypto".PrivKey has no field or method MarshalJSON) chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/evmcc/vendor/github.com/hyperledger/burrow/account/crypto.go:192:2: too many errors " `

Shirikatsu (Mon, 07 Jan 2019 09:49:27 GMT):
I could be doing this wrong, but I arrive at the same error when I use a different deployment method than using the docker-cli image in the `first-network` example.

MHBauer (Mon, 07 Jan 2019 18:28:43 GMT):
that looks like burro is off somehow

MHBauer (Mon, 07 Jan 2019 18:31:02 GMT):
or tmlibs?

MHBauer (Mon, 07 Jan 2019 18:36:31 GMT):
ya, somehow your tmlibs is more recent the 0.8.1

MHBauer (Mon, 07 Jan 2019 18:37:03 GMT):
@Shirikatsu have you tried to do somethin to the code or is this a fresh checkout?

seesemichaelj (Tue, 08 Jan 2019 01:34:05 GMT):
Has joined the channel.

Shirikatsu (Tue, 08 Jan 2019 09:55:03 GMT):
@MHBauer Thanks for the response. It's a fresh checkout of master indeed.

Shirikatsu (Tue, 08 Jan 2019 09:55:03 GMT):
@MHBauer Thanks for the response. On second look, I've run `dep` to grab dependencies that seem to have included different versions of the dependencies. Removing those seems to have fixed the issue :) Thank you

MHBauer (Tue, 08 Jan 2019 17:03:14 GMT):
phew

MHBauer (Tue, 08 Jan 2019 18:23:46 GMT):
@Shirikatsu I think we're both interested in what your impressions are of the chaincode and the proxy when you've had a chance to run through some scenarios.

lehors (Wed, 09 Jan 2019 13:15:42 GMT):
@swetha Is the intent of FAB-13384 to do a complete a renaming of fabproxy to fab3? I'm looking for ways to contribute and would be happy to submit a CR for this :)

lehors (Wed, 09 Jan 2019 13:15:42 GMT):
@swetha Is the intent of FAB-13384 to do a complete renaming of fabproxy to fab3? I'm looking for ways to contribute and would be happy to submit a CR for this :)

MHBauer (Wed, 09 Jan 2019 17:58:43 GMT):
@lehors yes, that's the idea.

lehors (Wed, 09 Jan 2019 18:48:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=wQBnwReucadv2CnCe) @MHBauer ok, I have done that :-)

lehors (Wed, 09 Jan 2019 18:51:45 GMT):
but we probably need to coordinate because this is impacting a lot of files obviously so anything else is going to require a rebase

lehors (Wed, 09 Jan 2019 18:51:45 GMT):
but we probably need to coordinate because this is impacting a lot of files obviously so anything else in progress is going to require a rebase

MHBauer (Wed, 09 Jan 2019 18:55:43 GMT):
yup, that's why we haven't done it yet.

MHBauer (Wed, 09 Jan 2019 18:55:58 GMT):
waiting for 1.4 twiddle-thumbs

MHBauer (Wed, 09 Jan 2019 18:56:38 GMT):
we need reviews of https://gerrit.hyperledger.org/r/28179 and https://gerrit.hyperledger.org/r/28566

lehors (Wed, 09 Jan 2019 19:01:49 GMT):
ok, I pushed the change I made but can update when you guys are ready

MHBauer (Wed, 09 Jan 2019 19:10:17 GMT):
@swetha maybe we try a gerrit topic branch for the burrow update?

swetha (Wed, 09 Jan 2019 19:11:54 GMT):
that could work. Compared the diff last night: `12 files changed, 531 insertions(+), 435 deletions(-)` That is of all commits excluding vendor. Though a large commit we could actually do it in one. It isn't as big as I was expecting

swetha (Wed, 09 Jan 2019 19:12:43 GMT):
and it looks release is about to come out https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md

lehors (Wed, 09 Jan 2019 19:14:08 GMT):
yes 1.4 is being released today, announced tomorrow

lehors (Wed, 09 Jan 2019 19:14:43 GMT):
are you guys changed both fabric and burrow at the same time?

lehors (Wed, 09 Jan 2019 19:14:43 GMT):
are you guys changing both fabric and burrow at the same time?

swetha (Wed, 09 Jan 2019 19:18:32 GMT):
nope, the change to fabric is done: https://gerrit.hyperledger.org/r/#/c/28279/

swetha (Wed, 09 Jan 2019 19:19:11 GMT):
we are waiting on the 1.4 release to merge that in

lehors (Wed, 09 Jan 2019 19:19:23 GMT):
ah ok

swetha (Wed, 09 Jan 2019 19:20:19 GMT):
The burrow change we are almost finished with: https://github.com/swetharepakula/fabric-chaincode-evm/tree/update-burrow

MHBauer (Thu, 10 Jan 2019 08:40:37 GMT):
yay stuff merged and reviewed

lehors (Thu, 10 Jan 2019 12:09:41 GMT):
well, I'm happy to report that all the tests I ran passed now

lehors (Thu, 10 Jan 2019 12:09:54 GMT):
I reran the whole wokshop scenario: no problem

lehors (Thu, 10 Jan 2019 12:10:29 GMT):
and then I tried using a different contract that failed before because of a lack of support for revert and it now functions as expected

lehors (Thu, 10 Jan 2019 12:11:50 GMT):
this is using the update-burrow branch from swethat's github fork

lehors (Thu, 10 Jan 2019 12:11:50 GMT):
this is using the update-burrow branch from swetha's github fork

lehors (Thu, 10 Jan 2019 12:12:33 GMT):
I do have one question but that's just me not knowing, how can I create several accounts with some ether to use?

lehors (Thu, 10 Jan 2019 12:13:11 GMT):
I have this contract that implements an auction and one needs to bid with ether from their account

lehors (Thu, 10 Jan 2019 12:13:46 GMT):
when I use the Remix JVM env I get a few account preloaded I can use

lehors (Thu, 10 Jan 2019 12:13:46 GMT):
when I use the Remix JVM env I get a few accounts preloaded I can use

lehors (Thu, 10 Jan 2019 12:14:19 GMT):
but when I switch to fab3 I get one account with zero eth, which makes it impossible to really test the contract

lehors (Thu, 10 Jan 2019 12:14:32 GMT):
any hint on how to get around that would be appreciated

lehors (Thu, 10 Jan 2019 12:14:46 GMT):
but otherwise: good job guys :)

MHBauer (Thu, 10 Jan 2019 18:18:05 GMT):
ether doesn't matter

MHBauer (Thu, 10 Jan 2019 18:18:19 GMT):
I think that's in the release notes, but if it isn't we should write that down.

MHBauer (Thu, 10 Jan 2019 18:18:47 GMT):
accounts are tied to the user account accessing fabric, so if you need more accounts, you need to make more fabric users.

MHBauer (Thu, 10 Jan 2019 18:22:34 GMT):
@lehors I made a topic branch and messed up the name, https://gerrit.hyperledger.org/r/#/q/topic:test+(status:open+OR+status:merged) is there a way to merge the whole thing in one go?

MHBauer (Thu, 10 Jan 2019 18:22:59 GMT):
or is it just too bad, so sad, golang is a mess?

swetha (Thu, 10 Jan 2019 19:03:51 GMT):
@lehors About the ether piece. You would have to alter the contract so that it takes in a token contract like ERC 20. Anything that uses native ether won't work in Fabric. Each Fab3 is associated only to a single user, so you won't get the list of accounts like JVM in remix.

Shirikatsu (Fri, 11 Jan 2019 14:44:16 GMT):
@MHBauer @swetha Hey guys, thanks again to you both for the call the other day. It's great to engage with you guys and hopefully we can do some great work together! If you guys are interested and have any questions, you can open issues on the Ion github or visit our gitter for some less formal things :) https://gitter.im/clearmatics/ion

lehors (Fri, 11 Jan 2019 15:06:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=EJ2oYTwddJes3o88c) @MHBauer unless your contract is payable... I know it doesn't matter in terms of execution cost but I have an auction contract where one bids with ether, I just don't know how to do that here because the account I get from fab3 has zero ether

lehors (Fri, 11 Jan 2019 15:07:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=wpNanXneW6jAjjuj7) @swetha Ok, I understand. I think this would be worth noting as a limitation in the documentation. Thanks.

guoger (Fri, 11 Jan 2019 15:44:15 GMT):
it would be nice to wire this to fabcoin when it's available > Anything that uses native ether won't work in Fabric

MHBauer (Fri, 11 Jan 2019 18:19:33 GMT):
ah, okay, I'm not familiar with that part of ether work. we do need to add that to the release notes.

lehors (Fri, 11 Jan 2019 19:51:07 GMT):
I agree @guoger, that would be cool

lehors (Fri, 11 Jan 2019 20:28:16 GMT):
it would be good to be able to have some substitute, even if it has no real value

lehors (Fri, 11 Jan 2019 20:28:16 GMT):
it would be good to have some substitute, even if it has no real value

lehors (Fri, 11 Jan 2019 20:28:50 GMT):
just so that one can run contracts that use ether

swetha (Fri, 11 Jan 2019 22:43:29 GMT):
@guoger & @cbf we need some reviews: events integration test: https://gerrit.hyperledger.org/r/#/c/28179/ integration test timeout: https://gerrit.hyperledger.org/r/#/c/28566/ burrow update to 0.23: https://gerrit.hyperledger.org/r/#/c/28596/ & https://gerrit.hyperledger.org/r/#/c/28597/

swetha (Fri, 11 Jan 2019 23:01:22 GMT):
@lehors, @MHBauer the burrow update and fab3 rename conflict with one another. We should determine what order we want them to go in and rebase the other. My preference would be the burrow update first because I think that would be more difficult to rebase

MHBauer (Sat, 12 Jan 2019 00:59:30 GMT):
nobody's PR gets merged until they review two things! :-D

guoger (Sat, 12 Jan 2019 01:00:21 GMT):
reviewing it now

guoger (Sat, 12 Jan 2019 01:05:40 GMT):
when we create a CR that's related to an existing but closed JIRA, pls open a new JIRA and link to that. So we can have a proper description and keep track of the progress of project (X close, Y in review, Z in progress). I know I may said that if it's really a simple fix, we could simply piggyback that to an old one. but let's not do that anymore, i was wrong.

MHBauer (Sat, 12 Jan 2019 01:08:34 GMT):
ok

guoger (Sat, 12 Jan 2019 02:04:56 GMT):
+2'ed https://gerrit.hyperledger.org/r/c/28179/, w/ some comments there

swetha (Sun, 13 Jan 2019 07:57:04 GMT):
Yup, sorry I had closed the events jira too soon. but the CR was submitted with that jira was open

swetha (Sun, 13 Jan 2019 07:57:04 GMT):
Yup, sorry I had closed the events jira too soon. but the CR was submitted when that jira was open

lehors (Sun, 13 Jan 2019 19:54:56 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=oSfqfTGvNgBhsrxLc) @swetha As I said on Jira I too think the Burrow update should be merged first. I'll be happy to rebase my CR once that's done. No worries.

MHBauer (Thu, 17 Jan 2019 21:02:18 GMT):
what's left on release checklist? tweaking release notes &?

MHBauer (Thu, 17 Jan 2019 21:03:29 GMT):
still need reviews of update-burrow branch, I'd appreciate any eyes and any comments. https://gerrit.hyperledger.org/r/#/q/status:open+project:fabric-chaincode-evm+branch:master+topic:update-burrow

swetha (Thu, 17 Jan 2019 23:00:30 GMT):
@MHBauer still reviews on the release notes

swetha (Thu, 17 Jan 2019 23:00:30 GMT):
@MHBauer still need reviews on the release notes

swetha (Thu, 17 Jan 2019 23:00:37 GMT):
https://gerrit.hyperledger.org/r/#/c/28646/

narendranathreddy (Mon, 21 Jan 2019 10:01:00 GMT):
Has joined the channel.

narendranathreddy (Mon, 21 Jan 2019 11:19:03 GMT):
instantiate

narendranathreddy (Mon, 21 Jan 2019 11:24:18 GMT):
hello @swetha Swetha I have been trying to instantiate evmcc chaincode, Iam not using fabric samples instead iam using my modified project

narendranathreddy (Mon, 21 Jan 2019 11:24:34 GMT):
iam getting package not found error \

narendranathreddy (Mon, 21 Jan 2019 11:24:48 GMT):
proposalResponses:Error: error starting container: error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "chaincode/input/src/github.com/evmcc/go/evmcc.go:15:2: cannot find package "github.com/golang/protobuf/proto" in any of: /opt/go/src/github.com/golang/protobuf/proto (from $GOROOT) /chaincode/input/src/github.com/golang/protobuf/proto (from $GOPATH) /opt/gopath/src/github.com/golang/protobuf/proto chaincode/input/src/github.com/evmcc/go/evmcc.go:16:2: cannot find package "github.com/hyperledger/burrow/account" in any of: /opt/go/src/github.com/hyperledger/burrow/account (from $GOROOT) /chaincode/input/src/github.com/hyperledger/burrow/account (from $GOPATH) /opt/gopath/src/github.com/hyperledger/burrow/account chaincode/input/src/github.com/evmcc/go/evmcc.go:17:2: cannot find package "github.com/hyperledger/burrow/binary" in any of: /opt/go/src/github.com/hyperledger/burrow/binary (from $GOROOT) /chaincode/input/src/github.com/hyperledger/burrow/binary (from $GOPATH) /opt/gopath/src/github.com/hyperledger/burrow/binary chaincode/input/src/github.com/evmcc/go/evmcc.go:18:2: cannot find package "github.com/hyperledger/burrow/execution/evm" in any of: /opt/go/src/github.com/hyperledger/burrow/execution/evm (from $GOROOT) /chaincode/input/src/github.com/hyperledger/burrow/execution/evm (from $GOPATH) /opt/gopath/src/github.com/hyperledger/burrow/execution/evm chaincode/input/src/github.com/evmcc/go/evmcc.go:19:2: cannot find package "github.com/hyperledger/burrow/logging" in any of: /opt/go/src/github.com/hyperledger/burrow/logging (from $GOROOT) /chaincode/input/src/github.com/hyperledger/burrow/logging (from $GOPATH) /opt/gopath/src/github.com/hyperledger/burrow/logging chaincode/input/src/github.com/evmcc/go/evmcc.go:20:2: cannot find package "github.com/hyperledger/fabric-chaincode-evm/event" in any of: /opt/go/src/github.com/hyperledger/fabric-chaincode-evm/event (from $GOROOT) /chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/event (from $GOPATH) /opt/gopath/src/github.com/hyperledger/fabric-chaincode-evm/event chaincode/input/src/github.com/evmcc/go/evmcc.go:21:2: cannot find package "github.com/hyperledger/fabric-chaincode-evm/statemanager" in any of: /opt/go/src/github.com/hyperledger/fabric-chaincode-evm/statemanager (from $GOROOT) /chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/statemanager (from $GOPATH) /opt/gopath/src/github.com/hyperledger/fabric-chaincode-evm/statemanager chaincode/input/src/github.com/evmcc/go/evmcc.go:26:2: cannot find package "golang.org/x/crypto/sha3" in any of: /opt/go/src/golang.org/x/crypto/sha3 (from $GOROOT) /chaincode/input/src/golang.org/x/crypto/sha3 (from $GOPATH) /opt/gopath/src/golang.org/x/crypto/sha3 ",Error: error starting container: error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "chaincode/input/src/github.com/evmcc/go/evmcc.go:15:2: cannot find package "github.com/golang/protobuf/proto" in any of: /opt/go/src/github.com/golang/protobuf/proto (from $GOROOT) /chaincode/input/src/github.com/golang/protobuf/proto (from $GOPATH) /opt/gopath/src/github.com/golang/protobuf/proto chaincode/input/src/github.com/evmcc/go/evmcc.go:16:2: cannot find package "github.com/hyperledger/burrow/account" in any of: /opt/go/src/github.com/hyperledger/burrow/account (from $GOROOT) /chaincode/input/src/github.com/hyperledger/burrow/account (from $GOPATH) /opt/gopath/src/github.com/hyperledger/burrow/account

narendranathreddy (Mon, 21 Jan 2019 11:25:09 GMT):
above are peer logs

narendranathreddy (Mon, 21 Jan 2019 11:26:13 GMT):

Clipboard - January 21, 2019 3:26 PM

ycarmel (Tue, 22 Jan 2019 08:44:28 GMT):
Has joined the channel.

Jamie (Tue, 22 Jan 2019 17:09:33 GMT):
Has joined the channel.

incarose (Wed, 23 Jan 2019 00:23:17 GMT):
Has joined the channel.

MHBauer (Wed, 23 Jan 2019 18:47:53 GMT):
@lehors thanks for review

lehors (Wed, 23 Jan 2019 19:31:58 GMT):
you bet

MHBauer (Wed, 23 Jan 2019 23:54:34 GMT):
@swetha so release is out now?

MHBauer (Wed, 23 Jan 2019 23:54:44 GMT):
Do we have an announcement somewhere?

swetha (Wed, 23 Jan 2019 23:56:12 GMT):
@MHBauer yes the release is out

swetha (Wed, 23 Jan 2019 23:56:30 GMT):
https://github.com/hyperledger/fabric-chaincode-evm/releases/tag/v0.1.0

lehors (Thu, 24 Jan 2019 15:58:49 GMT):
congrats! :)

lehors (Thu, 24 Jan 2019 16:01:12 GMT):
you should send an email to the fabric mailing list though

MHBauer (Thu, 24 Jan 2019 17:55:56 GMT):
@guoger thanks for looking at the PRs

swetha (Fri, 25 Jan 2019 19:11:07 GMT):
@lehors forgot about the mailing list. i will do that now

swetha (Fri, 25 Jan 2019 20:00:47 GMT):
@lehors we merged in the burrow update

lehors (Fri, 25 Jan 2019 21:14:26 GMT):
nice! :-)

lehors (Fri, 25 Jan 2019 22:04:08 GMT):
@swetha hmm... make integration-test fails for me unfortunately :-(

lehors (Fri, 25 Jan 2019 22:05:22 GMT):
`------------------------------ • Failure [120.924 seconds] Fabproxy [It] implements the ethereum json rpc api /Users/lehors/Projects/Go/src/github.com/hyperledger/fabric-chaincode-evm/integration/fab3/fab3_test.go:137 Timed out after 60.005s. Expected : { Code: -32000, Message: "Failed to query the ledger: QueryBlockByTxID failed: Transaction processing for endorser [localhost:30008]: Chaincode status Code: (500) UNKNOWN. Description: Failed to get block for txID cbd18f1d112a60f28f8c1a1fa6211f762a441c824293b38c18e5712db7edd828, error Entry not found in index", Data: "", } to be zero-valued /Users/lehors/Projects/Go/src/github.com/hyperledger/fabric-chaincode-evm/integration/fab3/fab3_test.go:198 ------------------------------ Summarizing 1 Failure: [Fail] Fabproxy [It] implements the ethereum json rpc api /Users/lehors/Projects/Go/src/github.com/hyperledger/fabric-chaincode-evm/integration/fab3/fab3_test.go:198 Ran 1 of 1 Specs in 137.411 seconds FAIL! -- 0 Passed | 1 Failed | 0 Pending | 0 Skipped --- FAIL: TestWeb3 (137.42s) `

lehors (Fri, 25 Jan 2019 22:06:29 GMT):
@MHBauer ^^

swetha (Fri, 25 Jan 2019 22:10:27 GMT):
@lehors, unfortunately i think it is a flaky test. are you consistently having that error?

lehors (Fri, 25 Jan 2019 22:11:01 GMT):
I got it a couple of times, I can try more and will let you know

swetha (Fri, 25 Jan 2019 22:12:10 GMT):
okay, i have seen that error before locally

swetha (Fri, 25 Jan 2019 22:12:42 GMT):
it is definitely a timing issue of some sort, where we query for the block before it has been added

lehors (Fri, 25 Jan 2019 22:13:00 GMT):
I see

lehors (Fri, 25 Jan 2019 22:13:34 GMT):
maybe the test should pause

lehors (Fri, 25 Jan 2019 22:13:51 GMT):
we have pauses in some of the fabric tests

lehors (Fri, 25 Jan 2019 22:16:15 GMT):
ok, I tried again and it passed

lehors (Fri, 25 Jan 2019 22:16:28 GMT):
so, not so bad

swetha (Fri, 25 Jan 2019 22:18:52 GMT):
I also accidentally merged another patch in which affects the file `fabproxy/ethservice_types_roundtrip_test.go`, which I think will affect your rebase. So, sorry about that

lehors (Fri, 25 Jan 2019 22:24:31 GMT):
yes, it did :)

lehors (Fri, 25 Jan 2019 22:24:43 GMT):
it's ok, I just pushed another rebase

lehors (Fri, 25 Jan 2019 22:25:41 GMT):
I was like "what?? why does it say there is a merge conflict, I just rebased??" :)

swetha (Fri, 25 Jan 2019 22:26:05 GMT):
hahah, i clicked merge and then realized what I did

lehors (Fri, 25 Jan 2019 22:28:48 GMT):
well, I'm taking off (it's 11:30pm here) so it's on you now

lehors (Fri, 25 Jan 2019 22:29:33 GMT):
all the tests passed so I'm confident I didn't make things worse :)

lehors (Fri, 25 Jan 2019 22:30:12 GMT):
ttyl

MHBauer (Fri, 25 Jan 2019 22:35:22 GMT):
rebase looking good, thanks.

swetha (Fri, 25 Jan 2019 22:46:10 GMT):
thanks arnaud! merged it all in :)

MHBauer (Fri, 25 Jan 2019 22:54:03 GMT):
boom,

MHBauer (Fri, 25 Jan 2019 23:00:56 GMT):
@swetha oh wait, did we fix the contract init events?

MHBauer (Fri, 25 Jan 2019 23:01:02 GMT):
I forgot about that

swetha (Fri, 25 Jan 2019 23:01:34 GMT):
yes i fixed it and added tests for it

MHBauer (Fri, 25 Jan 2019 23:01:59 GMT):
yup, NAILED IT

MHBauer (Fri, 25 Jan 2019 23:02:25 GMT):
I didn't notice the new ones

swetha (Fri, 25 Jan 2019 23:17:49 GMT):
https://github.com/hyperledger/fabric-chaincode-evm/blob/master/evmcc/evmcc_test.go#L598-L650

MHBauer (Fri, 25 Jan 2019 23:37:22 GMT):
nope, didn't read it

Pradeep_Pentakota (Sat, 26 Jan 2019 13:42:23 GMT):
Has joined the channel.

binhn (Sat, 26 Jan 2019 16:50:16 GMT):
Has left the channel.

edisinovcic (Mon, 28 Jan 2019 13:16:06 GMT):
Has joined the channel.

MHBauer (Mon, 28 Jan 2019 17:41:35 GMT):
I feel like we need to start abstracting some of the stuff like https://github.com/hyperledger/fabric-chaincode-evm/blob/master/evmcc/evmcc_test.go#L603-L606

MHBauer (Mon, 28 Jan 2019 17:41:46 GMT):
the comments are nice, tho

andrewyu (Tue, 29 Jan 2019 06:13:49 GMT):
Has joined the channel.

andrewyu (Tue, 29 Jan 2019 06:36:38 GMT):
Hey all, I just put in a pull request, there is an issue which came about from renaming fabproxy to fab3: https://github.com/hyperledger/fabric-chaincode-evm/pull/2

cbf (Tue, 29 Jan 2019 14:55:57 GMT):
@andrewyu please file a JIRA and submit a Gerrit CR per the contributing guidelines in Fabric

cbf (Tue, 29 Jan 2019 14:56:11 GMT):
we only use GH as a mirror of the code managed by Gerrit

cbf (Tue, 29 Jan 2019 14:56:31 GMT):
https://hyperledger-fabric.readthedocs.io/en/release-1.4/CONTRIBUTING.html

swetha (Tue, 29 Jan 2019 18:32:26 GMT):
I have already created a JIRA for the issue that you can reference in yoru commit: https://jira.hyperledger.org/browse/FAB-13947

swetha (Tue, 29 Jan 2019 18:32:26 GMT):
I have already created a JIRA for the issue that you can reference in your commit: https://jira.hyperledger.org/browse/FAB-13947

swetha (Tue, 29 Jan 2019 18:32:38 GMT):
@andrewyu ^

andrewyu (Tue, 29 Jan 2019 21:27:53 GMT):
ok noted thanks

swetha (Tue, 29 Jan 2019 23:05:13 GMT):
reviews needed for https://gerrit.hyperledger.org/r/#/c/28903/ & https://gerrit.hyperledger.org/r/#/c/28905/

guoger (Wed, 30 Jan 2019 15:50:20 GMT):
@swetha I'm still in the middle of it. not super familiar with viper but it looks almost good to go. Also i noticed discussion between morgan and i want to put more thoughts to it/

swetha (Wed, 30 Jan 2019 18:47:07 GMT):
sounds good!

MHBauer (Wed, 30 Jan 2019 23:32:07 GMT):
@guoger anything left on https://gerrit.hyperledger.org/r/28566 ?

MHBauer (Thu, 31 Jan 2019 02:30:16 GMT):
so for jira, do I task-ize concepts?

guoger (Thu, 31 Jan 2019 02:44:37 GMT):
you lost me there

guoger (Thu, 31 Jan 2019 02:44:43 GMT):
what do you mean?

guoger (Thu, 31 Jan 2019 02:45:09 GMT):
btw, @swetha you might want to rebase your patches

MHBauer (Thu, 31 Jan 2019 03:36:49 GMT):
https://gerrit.hyperledger.org/r/#/c/28949/ should be a tiny bit more than the minimum viable, and I'll put the filtering work into a follow up, so we can focus on having the next step for truffle.

MHBauer (Thu, 31 Jan 2019 03:37:10 GMT):
basically, I don't know how to use jira

MHBauer (Thu, 31 Jan 2019 03:37:18 GMT):
and we've got a web of dependencies.

MHBauer (Thu, 31 Jan 2019 03:37:31 GMT):
and I want to get smaller pieces in

MHBauer (Thu, 31 Jan 2019 03:38:06 GMT):
thanks for review @guoger

MHBauer (Thu, 31 Jan 2019 03:39:38 GMT):
is there a "proposal" jira thingy?

guoger (Thu, 31 Jan 2019 03:39:47 GMT):
do you wanna have a quick zoom/slack session?

MHBauer (Thu, 31 Jan 2019 03:39:53 GMT):
I think we need to establish a mini-framework or scenario for our block setup

MHBauer (Thu, 31 Jan 2019 03:40:58 GMT):
@guoger if you want to, I don't know if @swetha is around.

guoger (Thu, 31 Jan 2019 03:42:12 GMT):
one quick question first, i'm looking at https://gerrit.hyperledger.org/r/c/28903/, when i build, i'm getting a binary `main`. shouldn't it be `fab3`?

MHBauer (Thu, 31 Jan 2019 03:42:37 GMT):
for make? or

MHBauer (Thu, 31 Jan 2019 03:42:40 GMT):
how are you building?

guoger (Thu, 31 Jan 2019 03:42:47 GMT):
(i mean of course i could `go build -o`, but i thought i should be able to get `fab3` just by `go build`?

MHBauer (Thu, 31 Jan 2019 03:42:59 GMT):
it would come out 'cmd' I believe

guoger (Thu, 31 Jan 2019 03:43:11 GMT):
ah, yes, sorry, it is `cmd`

guoger (Thu, 31 Jan 2019 03:43:14 GMT):
but why

MHBauer (Thu, 31 Jan 2019 03:43:18 GMT):
that's the name of the folder.

MHBauer (Thu, 31 Jan 2019 03:43:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=pnsMoDBXyqZRSpnNs) @MHBauer oh, of course...

MHBauer (Thu, 31 Jan 2019 03:43:29 GMT):
but not the package?

MHBauer (Thu, 31 Jan 2019 03:43:46 GMT):
confusing, but that's why.

MHBauer (Thu, 31 Jan 2019 03:44:03 GMT):
don't bring logic in to this and ask go to make sense...

guoger (Thu, 31 Jan 2019 03:44:23 GMT):
haha

guoger (Thu, 31 Jan 2019 03:44:38 GMT):
but again, shouldn't we make it produce a binary named `fab3`?

MHBauer (Thu, 31 Jan 2019 03:44:42 GMT):
I wrote the makefile, so I use the makefile

MHBauer (Thu, 31 Jan 2019 03:44:56 GMT):
and that shoudl produce a fab3

MHBauer (Thu, 31 Jan 2019 03:45:15 GMT):
as 'bin/fab3'

MHBauer (Thu, 31 Jan 2019 03:45:15 GMT):
as `bin/fab3`

guoger (Thu, 31 Jan 2019 03:45:26 GMT):
yep

guoger (Thu, 31 Jan 2019 03:45:32 GMT):
but anyway, just a nit

MHBauer (Thu, 31 Jan 2019 03:45:47 GMT):
¯\_(ツ)_/¯

guoger (Thu, 31 Jan 2019 03:45:48 GMT):
(and a bit surprised when i saw `cmd`)

MHBauer (Thu, 31 Jan 2019 03:45:53 GMT):
oh great, that works here too.

guoger (Thu, 31 Jan 2019 03:46:00 GMT):
lol

MHBauer (Thu, 31 Jan 2019 03:46:22 GMT):
well, that's why you normally see a different directory structure.

MHBauer (Thu, 31 Jan 2019 03:46:31 GMT):
at least, among the go projects I've noticed.

guoger (Thu, 31 Jan 2019 03:46:36 GMT):
it took me 5 seconds to realize it's shrug

MHBauer (Thu, 31 Jan 2019 03:46:44 GMT):
CF stuff seems to shove everything into the top-level.

MHBauer (Thu, 31 Jan 2019 03:47:02 GMT):
so I can forgove jb & qs .

guoger (Thu, 31 Jan 2019 03:47:02 GMT):
so `fabric-chaincode-evm/cmd/fab3/main.go`?

MHBauer (Thu, 31 Jan 2019 03:47:21 GMT):
ya, something like that is what *I* would expect.

guoger (Thu, 31 Jan 2019 03:47:23 GMT):
what's jb&qs?

MHBauer (Thu, 31 Jan 2019 03:47:34 GMT):
johny berk

MHBauer (Thu, 31 Jan 2019 03:47:38 GMT):
and queen swe

guoger (Thu, 31 Jan 2019 03:48:13 GMT):
i was gonna ask who's johny berk but i guess i'll just keep that to myself

MHBauer (Thu, 31 Jan 2019 03:49:07 GMT):
other local here.

MHBauer (Thu, 31 Jan 2019 03:49:21 GMT):
could have sworn you've met, but maybe not at all now that I think of it.

MHBauer (Thu, 31 Jan 2019 03:49:41 GMT):
anyway, back on the topic of fab3,

guoger (Thu, 31 Jan 2019 03:49:45 GMT):
https://zoom.us/j/766717353

PadmavathyMohan (Thu, 31 Jan 2019 05:50:11 GMT):
Has joined the channel.

guoger (Thu, 31 Jan 2019 06:54:38 GMT):
I did a bit restructuring of JIRAs: *epic* FAB-14000 - _support toolsings in Ethereum ecosystem_ \vdash *story* FAB-13999 - _As a fabric evm chaincode user, I want to interact with my contract via Ethereum JSON RPC_ \vdash FAB-13578 - _Implement getStorageAt_ \vdash etc \vdash *story* FAB-14000 - _As a Truffle developer, i want to use Fab3 as backend_

guoger (Thu, 31 Jan 2019 06:54:38 GMT):
I did a bit restructuring of JIRAs: *epic* FAB-14000 - _support toolsings in Ethereum ecosystem_ \[\vdash] *story* FAB-13999 - _As a fabric evm chaincode user, I want to interact with my contract via Ethereum JSON RPC_ \vdash FAB-13578 - _Implement getStorageAt_ \vdash etc \vdash *story* FAB-14000 - _As a Truffle developer, i want to use Fab3 as backend_

guoger (Thu, 31 Jan 2019 06:54:38 GMT):
I did a bit restructuring of JIRAs: ``` *epic* FAB-14000 - _support toolsings in Ethereum ecosystem_ |- *story* FAB-13999 - _As a fabric evm chaincode user, I want to interact with my contract via Ethereum JSON RPC_ |- *sub-task* FAB-13578 - _Implement getStorageAt_ |- etc |- *story* FAB-14000 - _As a Truffle developer, i want to use Fab3 as backend_ ```

guoger (Thu, 31 Jan 2019 06:54:38 GMT):
I did a bit restructuring of JIRAs: ``` *epic* FAB-14000 - support toolsings in Ethereum ecosystem |- *story* FAB-13999 - As a fabric evm chaincode user, I want to interact with my contract via Ethereum JSON RPC |- *sub-task* FAB-13578 - Implement getStorageAt |- etc |- *story* FAB-14000 - As a Truffle developer, i want to use Fab3 as backend ```

guoger (Thu, 31 Jan 2019 08:43:28 GMT):
is https://gerrit.hyperledger.org/r/c/28949 ready for review? or still wip

huanlv94 (Thu, 31 Jan 2019 09:07:00 GMT):
Has joined the channel.

MHBauer (Thu, 31 Jan 2019 16:13:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=eJ969P38sv95CqsgY) @guoger to me, should be done, more work in future stuff

swetha (Thu, 31 Jan 2019 18:05:09 GMT):
@guoger little confused with the restructuring. so we now have an epic in which a story is an issue in it? And why do we pick sub tasks over tasks? Asking just to understand how we should structure things in the future

swetha (Thu, 31 Jan 2019 18:05:09 GMT):
@guoger little confused with the restructuring. so we now have an epic in which a story is an issue in it? And why do we pick sub tasks over tasks? Asking to understand how we should structure things in the futur

swetha (Thu, 31 Jan 2019 21:39:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=QuT2e9r6ouZTDTjhr) @guoger The only concern I had about going to this directory structure is because the evmcc main cannot go there which would make it seem that the main command is fab3 in this repo which isn't necessarily true. But since more people would be using fab3 day to day and need to build it over evmcc I can put a jira in the backlog to change this. @guoger @MHBauer ^^

swetha (Thu, 31 Jan 2019 23:02:10 GMT):
@MHBauer & @guoger : this patch has been rebased and needs another round of reviews

MHBauer (Fri, 01 Feb 2019 01:57:18 GMT):
what if we make a toplevel jira epic/story for various refactorings? A holder that we can toss nits under as we see it, so it can be part of a thing that's not blocking anything.

MHBauer (Fri, 01 Feb 2019 01:57:33 GMT):
can add stuff and tackle it separately as we see it.

MHBauer (Fri, 01 Feb 2019 01:58:52 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=AE9PKbShwm2F79h27) @swetha I don't know if we actually need to change it, but something about the current structure seems to be violating expectations, even for people who I'd assume would know better.

MHBauer (Fri, 01 Feb 2019 02:00:04 GMT):
and I don't view cmd as "this is the ONLY relevant thing in the repo", I view it as, "hey, here's my user visible thing, that a person would want to interact with". as we've discussed, evmcc isn't a deliverable, the code is. So I don't understand

MHBauer (Fri, 01 Feb 2019 02:02:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=itTG6XCk5sNYwE9Fw) more than that, we can assign it and assign reviewers I think. then it's "I promise to do this in a follow up or other change, and you promise to review it when you see it".

MHBauer (Fri, 01 Feb 2019 02:20:49 GMT):
like how do you write a user story for code changes. that seems silly

swetha (Fri, 01 Feb 2019 02:24:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=itTG6XCk5sNYwE9Fw) @MHBauer I agree for some large refactors that we should create jiras. but like the once i suggested in this patch: https://gerrit.hyperledger.org/r/#/c/28949/, since it is an introduction of new code, it would be easier to tackle the refactor at the beginning and never introduce the duplication of code at all. This way we don't accumulate too much technical debt.

swetha (Fri, 01 Feb 2019 02:24:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=itTG6XCk5sNYwE9Fw) @MHBauer I agree for some large refactors that we should create jiras. but like the ones i suggested in this patch: https://gerrit.hyperledger.org/r/#/c/28949/, since it is an introduction of new code, it would be easier to tackle the refactor at the beginning and never introduce the duplication of code at all. This way we don't accumulate too much technical debt.

swetha (Fri, 01 Feb 2019 02:26:18 GMT):
Otherwise for refactors we notice after code as been merged I think you can still add a task JIRA. It doesn't necessarily all have to be user facing

MHBauer (Fri, 01 Feb 2019 02:31:06 GMT):
I don't like how it make stuff bigger and confused, that is why I ask.

MHBauer (Fri, 01 Feb 2019 02:31:29 GMT):
one of my commits is ORANGE

MHBauer (Fri, 01 Feb 2019 02:31:33 GMT):
I DON'T LIKE IT

guoger (Fri, 01 Feb 2019 02:34:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=jmmBanmv39ComsHF6) @swetha Ah, don't read them too literally. It's as simple as a tree with height == 2. So, you can just interpret `issue` as stories under epic. We pick sub-task, because you can only create sub-task under story, not task

MHBauer (Fri, 01 Feb 2019 02:34:45 GMT):
I made some more, but I can't figure out how to change some of the fields

guoger (Fri, 01 Feb 2019 02:34:55 GMT):
which one?

swetha (Fri, 01 Feb 2019 02:35:04 GMT):
what jay said ^

MHBauer (Fri, 01 Feb 2019 02:35:20 GMT):
how do I change status

MHBauer (Fri, 01 Feb 2019 02:35:31 GMT):
todo to inprogress or inprogrress to done?

guoger (Fri, 01 Feb 2019 02:35:39 GMT):
click on start working

swetha (Fri, 01 Feb 2019 02:35:40 GMT):
there is a button in jira

MHBauer (Fri, 01 Feb 2019 02:35:48 GMT):
"begin work"?

guoger (Fri, 01 Feb 2019 02:35:53 GMT):
yep

guoger (Fri, 01 Feb 2019 02:35:57 GMT):
it's like a state machine

MHBauer (Fri, 01 Feb 2019 02:36:01 GMT):
that's silly

guoger (Fri, 01 Feb 2019 02:36:08 GMT):
you cannot `SetState`, but only `Step`

swetha (Fri, 01 Feb 2019 02:36:10 GMT):

Screen Shot 2019-01-31 at 6.35.50 PM.png

MHBauer (Fri, 01 Feb 2019 02:36:21 GMT):
that says accept

swetha (Fri, 01 Feb 2019 02:36:23 GMT):
First thing to do is click `Accept`

MHBauer (Fri, 01 Feb 2019 02:36:33 GMT):
Never esen that one

guoger (Fri, 01 Feb 2019 02:36:47 GMT):
hold on, it looks different here

guoger (Fri, 01 Feb 2019 02:36:55 GMT):
for FAB-13600

MHBauer (Fri, 01 Feb 2019 02:37:13 GMT):
what a terrible tool, I hope we're not paying for it.

swetha (Fri, 01 Feb 2019 02:37:19 GMT):
i didn't refresh after you did the restructuring

guoger (Fri, 01 Feb 2019 02:37:24 GMT):
Linux Foundation is paying i guess

MHBauer (Fri, 01 Feb 2019 02:37:41 GMT):
oh well, gotta keep atlasian in business

swetha (Fri, 01 Feb 2019 02:37:42 GMT):
which task are you looking at?

guoger (Fri, 01 Feb 2019 02:37:42 GMT):
although as open source community user, lower fee i guess

swetha (Fri, 01 Feb 2019 02:37:53 GMT):
i already put getLogs in progress and assigned to you

swetha (Fri, 01 Feb 2019 02:38:15 GMT):
so you won't be able to see the same buttons on your task

guoger (Fri, 01 Feb 2019 02:42:39 GMT):
sometimes if you want to change type of a jira, click on `move`

MHBauer (Fri, 01 Feb 2019 02:42:59 GMT):
so you get accept, because I'm assigned?

swetha (Fri, 01 Feb 2019 02:45:20 GMT):
no on any new task the first button you see there is accept

MHBauer (Fri, 01 Feb 2019 02:45:29 GMT):
should add an event to the simple storage contract

swetha (Fri, 01 Feb 2019 02:45:47 GMT):
the instructor contract already has an event

swetha (Fri, 01 Feb 2019 02:46:30 GMT):
which i just realized we didn't create a go version of that contract

swetha (Fri, 01 Feb 2019 02:46:31 GMT):
https://github.com/hyperledger/fabric-chaincode-evm/blob/master/integration/web3/instructor_contract.js

MHBauer (Fri, 01 Feb 2019 02:46:37 GMT):
yea, I know

MHBauer (Fri, 01 Feb 2019 02:46:46 GMT):
simple storage is easier.

MHBauer (Fri, 01 Feb 2019 02:46:50 GMT):
:-)

guoger (Fri, 01 Feb 2019 02:46:59 GMT):
btw, you can click on the workflow next to status

MHBauer (Fri, 01 Feb 2019 02:47:09 GMT):
ya, but you can't actually change it there

guoger (Fri, 01 Feb 2019 02:47:17 GMT):
different type of jira (task, bug) has different workflow

swetha (Fri, 01 Feb 2019 02:47:26 GMT):
i use a contract with events in the e2e tests

guoger (Fri, 01 Feb 2019 02:47:42 GMT):
right, because you shouldn't set state in FSM, you should step it

swetha (Fri, 01 Feb 2019 02:47:44 GMT):
oh nope i dont

guoger (Fri, 01 Feb 2019 02:47:57 GMT):
(and i don't like it in jira)

guoger (Fri, 01 Feb 2019 02:48:07 GMT):
silly extra clicks

swetha (Fri, 01 Feb 2019 02:48:38 GMT):
my preference is for you to use a different contract than altering simple storage, especially because simple storage is kind of like a hello world contract

MHBauer (Fri, 01 Feb 2019 02:49:24 GMT):
okay, I've already got LessSimpleStorage.sol written up.

MHBauer (Fri, 01 Feb 2019 02:49:34 GMT):
has been useful for debugging.

swetha (Fri, 01 Feb 2019 02:49:41 GMT):
lol, that should work

MHBauer (Fri, 01 Feb 2019 02:57:42 GMT):
oh ya, watch is pretty sweet.

guoger (Fri, 01 Feb 2019 02:58:19 GMT):
until you are watching a thousands of jira

MHBauer (Fri, 01 Feb 2019 03:01:14 GMT):
I meant ginkgo watch

MHBauer (Fri, 01 Feb 2019 03:01:31 GMT):
How can I make it open a filter by defaul tfor me?

MHBauer (Fri, 01 Feb 2019 03:01:45 GMT):
I want component=f-c-e

guoger (Fri, 01 Feb 2019 03:05:24 GMT):
i don' think so... you can store the filter though

MHBauer (Fri, 01 Feb 2019 03:25:44 GMT):
I made one I think

MHBauer (Fri, 01 Feb 2019 03:43:25 GMT):
when's the next release?

guoger (Fri, 01 Feb 2019 03:45:32 GMT):
fabric? or fabric-cc-evm?

MHBauer (Fri, 01 Feb 2019 04:02:17 GMT):
us

MHBauer (Fri, 01 Feb 2019 04:02:23 GMT):
f-c-e

MHBauer (Fri, 01 Feb 2019 04:32:21 GMT):
I ask because I wanna get that sweet sweet new burrow out.

guoger (Fri, 01 Feb 2019 04:46:57 GMT):
i guess anything before 1.0 can be very flexible. we can even have a 0.1.1 :)

MHBauer (Fri, 01 Feb 2019 04:53:53 GMT):
that'd be great.

MHBauer (Fri, 01 Feb 2019 04:54:04 GMT):
rapid releases, continuous even!

guoger (Fri, 01 Feb 2019 07:51:18 GMT):
which counterfeiter version are you guys using?

guoger (Fri, 01 Feb 2019 07:51:36 GMT):
(IIRC, it's not enforced by project, correct?)

swetha (Fri, 01 Feb 2019 16:54:38 GMT):
@guoger im using this sha: c936c3d9d00c3bc9158f53f49cd70ff3214ac0b8

swetha (Fri, 01 Feb 2019 16:55:42 GMT):
if we think we might be altering the mocks often enough we should vendor it in. i will put a jira in

MHBauer (Fri, 01 Feb 2019 19:13:02 GMT):
yea, we should do that since it has no versions.

MHBauer (Fri, 01 Feb 2019 19:14:05 GMT):
oh, they made a release!

MHBauer (Fri, 01 Feb 2019 19:14:06 GMT):
https://github.com/maxbrunsfeld/counterfeiter/releases/tag/v6.0.0

MHBauer (Fri, 01 Feb 2019 19:14:19 GMT):
https://github.com/maxbrunsfeld/counterfeiter/releases/tag/v6.0.1

swetha (Fri, 01 Feb 2019 19:41:17 GMT):
nice we can start using those then

MHBauer (Fri, 01 Feb 2019 20:11:41 GMT):
@guoger you seemed happy with https://gerrit.hyperledger.org/r/#/c/29019/ but didn't +2 ?

pasimoes (Sat, 02 Feb 2019 00:58:37 GMT):
Has joined the channel.

lehors (Mon, 04 Feb 2019 16:59:51 GMT):
@MHBauer @guoger fyi Jira is set to work that way. It wasn't before. So, don't blame the tool if you don't like it, blame whoever set it up that way. :-) I too think it's a bit clunky - it takes a lot of steps that don't seem really useful - but before we had a mess because nobody knew what process flow was to be followed and you could set the state to any value in any order

MHBauer (Mon, 04 Feb 2019 18:49:21 GMT):
make ssense, but they put the button in the wrong place :-)

swetha (Mon, 04 Feb 2019 19:44:42 GMT):
@andrewyu Are you still intersted in making a fix for https://jira.hyperledger.org/browse/FAB-13947. Please let us know if you need any help from us

guoger (Tue, 05 Feb 2019 02:59:38 GMT):
wow, how did we get jenkins build notification here?

MHBauer (Tue, 05 Feb 2019 06:20:37 GMT):
I blame @swetha

MHBauer (Tue, 05 Feb 2019 06:21:11 GMT):
I think it posts because it's a failure after merge.

MHBauer (Tue, 05 Feb 2019 06:22:07 GMT):
not sure if it's a jenkins error or if it's the same hang I've been seeing.

swetha (Tue, 05 Feb 2019 17:55:03 GMT):
@guoger I got them to change the jenkins notification to come here instead of the jenkins failure channel

swetha (Tue, 05 Feb 2019 17:55:38 GMT):
Some interruption occurred on build. Nothing to do with our test

swetha (Tue, 05 Feb 2019 17:56:08 GMT):
@MHBauer we solved your hang though. We wouldn't have environment variable collusion on jenkins

MahmoudKhraisha (Tue, 05 Feb 2019 20:57:27 GMT):
Has joined the channel.

DJEMOA (Wed, 06 Feb 2019 13:21:10 GMT):
Has joined the channel.

DJEMOA (Wed, 06 Feb 2019 13:25:11 GMT):
Hi everyone, please, I would like to know if it is possible to generate ABI and BYTECODE from a chaincode written in Go (for example) as we do in EVM using Solidity smart contract. Thanks in advance.

MHBauer (Wed, 06 Feb 2019 18:31:41 GMT):
@DJEMOA not relevant here, but interesting question.

MHBauer (Wed, 06 Feb 2019 18:32:34 GMT):
on a fabric CC, we have init and invoke, but the args given to each aren't typed, it's all strings/bytes. chaincode does what chaincode does.

JigneshVasoya (Fri, 08 Feb 2019 08:59:31 GMT):
Has joined the channel.

pravn1729 (Sun, 10 Feb 2019 08:44:19 GMT):
Has joined the channel.

lehors (Wed, 13 Feb 2019 17:25:22 GMT):
at some we're going to have take a serious look at it and nail down the test issue which makes the CI verification fails half the time...

lehors (Wed, 13 Feb 2019 17:25:22 GMT):
at some we're going to have take a serious look at it and nail down the test issue which makes the CI verification fail half the time...

MHBauer (Wed, 13 Feb 2019 17:30:43 GMT):
I've got a thought on one of them, but not the other.

MHBauer (Wed, 13 Feb 2019 17:31:28 GMT):
well, an interest in both.

MHBauer (Wed, 13 Feb 2019 17:32:26 GMT):
the one for build 156, I think we're trying to fast and need to wait more for stuff to start up, but I can't be sure. we're missing some err checks for sure.

MHBauer (Wed, 13 Feb 2019 17:32:39 GMT):
for the other one I think we're tearing down in the wrong order.

MHBauer (Wed, 13 Feb 2019 17:33:00 GMT):
might file a pr for each today.

MHBauer (Wed, 13 Feb 2019 17:36:51 GMT):
@lehors also filed a PR against upstream burrow to fix an issue https://github.com/hyperledger/burrow/pull/1014

lehors (Wed, 13 Feb 2019 18:14:55 GMT):
sounds good

MHBauer (Wed, 13 Feb 2019 21:45:19 GMT):
small change https://gerrit.hyperledger.org/r/#/c/29294/ that I think will help debug.

guoger (Thu, 14 Feb 2019 02:00:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=bZtAWXrvhsBFE7or3) @lehors fab3 integration tests fail me constantly... :(

MHBauer (Thu, 14 Feb 2019 06:55:15 GMT):
that's a new one that I haven't seen before.

MHBauer (Thu, 14 Feb 2019 06:56:05 GMT):
well, it's a different form of what I've already seen before.

MHBauer (Thu, 14 Feb 2019 07:00:07 GMT):
looks to me like we're turning it off before it's been fully started maybe.

swetha (Fri, 15 Feb 2019 02:50:26 GMT):
I think you are right, the issue is that proxy.Start is run in a separate goroutine, so if a signal comes before the httpServer in the start function is created, shutdown gets called when the httpServer is still nil. We should add both a nil check in the shutdown and add a wait to make sure the httpServer has started up. I will create a jira

swetha (Fri, 15 Feb 2019 04:28:14 GMT):
this CR should prevent the particular error: https://gerrit.hyperledger.org/r/#/c/29320/

swetha (Fri, 15 Feb 2019 07:02:54 GMT):
I think I have a fix for ^^. I will submit a patch tomorrow

MHBauer (Mon, 18 Feb 2019 20:57:48 GMT):
@swetha is https://jenkins.hyperledger.org/job/fabric-chaincode-evm-verify-x86_64/181/console this the same as another?

swetha (Mon, 18 Feb 2019 20:58:42 GMT):
yup same as the one right above

swetha (Mon, 18 Feb 2019 20:58:50 GMT):
as in the same error

MHBauer (Mon, 18 Feb 2019 20:59:50 GMT):
which fixes it?

MHBauer (Mon, 18 Feb 2019 20:59:58 GMT):
the refactor into one package?

MHBauer (Mon, 18 Feb 2019 21:00:07 GMT):
and how?

swetha (Mon, 18 Feb 2019 21:00:35 GMT):
this one fixes it: https://gerrit.hyperledger.org/r/#/c/29332/. Yup the refactor

swetha (Mon, 18 Feb 2019 21:01:35 GMT):
It fixes it because the fab3 package was already refactored to avoid this issue. The solution is stopping the proxy before bringing down the network because the SDK waits for I believe longer than 30 secs to kill the connection to the network which causes our tests to fail

MHBauer (Mon, 18 Feb 2019 21:02:05 GMT):
okay, need to look at how that worked in the fab3

MHBauer (Mon, 18 Feb 2019 21:43:56 GMT):
for this one

MHBauer (Mon, 18 Feb 2019 21:43:57 GMT):
https://jenkins.hyperledger.org/job/fabric-chaincode-evm-verify-x86_64/183/console

MHBauer (Mon, 18 Feb 2019 21:44:05 GMT):
I think we need to loop on the first git

MHBauer (Mon, 18 Feb 2019 22:11:34 GMT):
sounds like we need a loopy thing in a different area than where I thought. good discussion.

swetha (Mon, 18 Feb 2019 22:18:35 GMT):
created two jiras: https://jira.hyperledger.org/browse/FAB-14244 & https://jira.hyperledger.org/browse/FAB-14243 that should help address some of the flakes

MHBauer (Mon, 18 Feb 2019 22:37:01 GMT):
do we need gocov or manifest-tool in the tools makefile?

MHBauer (Mon, 18 Feb 2019 22:37:36 GMT):
wish we had something from fabric to vendor/submodule

MHBauer (Mon, 18 Feb 2019 23:02:36 GMT):
``` ```

MHBauer (Mon, 18 Feb 2019 23:02:36 GMT):
``` Hello Hyperledger Jobbuilder, I'd like you to reexamine a change. ```

MHBauer (Mon, 18 Feb 2019 23:02:58 GMT):
does the bot actually get an email and read it?

MHBauer (Mon, 18 Feb 2019 23:03:01 GMT):
funny

swetha (Tue, 19 Feb 2019 04:59:21 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=7BnbbiLNFXrfXEJRH) @MHBauer no we don't need either. Nothing in the makefile should be using it, except for the gotools target, which is addressed in a CR. But the CR doesn't remove those two from the gottols target

cbf (Wed, 20 Feb 2019 15:48:11 GMT):
@MHBauer https://gerrit.hyperledger.org/r/c/28352 pls update or abandon

MHBauer (Wed, 20 Feb 2019 18:47:21 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=pfvGqzKZv4FZg6RXX) @swetha can we shove removing them into another place where we're editing the tools makefile, or should it be a separate jira....

swetha (Wed, 20 Feb 2019 18:56:53 GMT):
@MHBauer I am ambivalent to removing them. I don't mind them staying in gotools as long as we aren't installing them in CI when we aren't using them. If you want them removed I can update this CR: https://gerrit.hyperledger.org/r/#/c/29322/ to add that change

MHBauer (Wed, 20 Feb 2019 19:08:21 GMT):
ya, that avoids installing them now,, so it achieves the goal, I guess, but I'm more at 'why leave it in'

MHBauer (Wed, 20 Feb 2019 19:08:27 GMT):
but, eh, dunno.

MHBauer (Wed, 20 Feb 2019 21:05:00 GMT):
how about metrics? future topic?

MHBauer (Wed, 20 Feb 2019 22:02:28 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=SeR7TY5Lb9CGnizp8) solved by https://gerrit.hyperledger.org/r/29370 I'm pretty sure

MHBauer (Wed, 20 Feb 2019 22:10:31 GMT):
@swetha we still want to do async-filters, right? people have been asking for it?

MHBauer (Wed, 20 Feb 2019 22:10:44 GMT):
e.g. newFilter, getFilterChanges, uninstallFilter ?

swetha (Wed, 20 Feb 2019 22:11:41 GMT):
@MHBauer yes

MHBauer (Wed, 20 Feb 2019 22:12:31 GMT):
cool

MHBauer (Wed, 20 Feb 2019 22:16:53 GMT):
@swetha looks like fabric just ignores it https://jira.hyperledger.org/browse/FAB-12172

MHBauer (Wed, 20 Feb 2019 22:17:33 GMT):
https://github.com/hyperledger/fabric/blob/release-1.4/Gopkg.toml#L14-L16

swetha (Wed, 20 Feb 2019 22:20:26 GMT):
But they are only ignoring the one package. It doesn't say how they dealt with the other packages. Also tagging cobra as noverify doesn't seem like the right thing when we aren't doing anything special to the cobra packages

MHBauer (Wed, 20 Feb 2019 23:19:53 GMT):
since the build machine seems pretty powerful, I wonder if we can do a `make -J4` or something

MHBauer (Wed, 20 Feb 2019 23:44:55 GMT):
@swetha where do you want dep mentioned?

swetha (Wed, 20 Feb 2019 23:55:32 GMT):
Lets actually address mentioning dep in the README as part of this: https://jira.hyperledger.org/browse/FAB-14059

MHBauer (Thu, 21 Feb 2019 21:00:02 GMT):
@swetha any recommendation to debug this

MHBauer (Thu, 21 Feb 2019 21:00:03 GMT):
``` ```

MHBauer (Thu, 21 Feb 2019 21:00:03 GMT):
``` Failure [91.924 seconds] [BeforeSuite] BeforeSuite /Users/mhb/go/src/github.com/hyperledger/fabric-chaincode-evm/integration/fab3/fab3_suite_test.go:45 Timed out after 60.003s. Expected process to exit. It did not. /Users/mhb/go/src/github.com/hyperledger/fabric-chaincode-evm/vendor/github.com/hyperledger/fabric/integration/nwo/deploy.go:108 ------------------------------ ```

MHBauer (Thu, 21 Feb 2019 21:00:18 GMT):
failing in suite setup? not sure what to think

swetha (Thu, 21 Feb 2019 21:00:25 GMT):
the network didn't come up

swetha (Thu, 21 Feb 2019 21:00:47 GMT):
either the network didn't come up or the chaincode didn't deploy

MHBauer (Thu, 21 Feb 2019 21:01:02 GMT):
any idea why it would happen over and over?

MHBauer (Thu, 21 Feb 2019 21:01:30 GMT):
some leftover that never got cleaned up

MHBauer (Thu, 21 Feb 2019 21:01:50 GMT):
``` docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 4e1f8add8ab0 hyperledger/fabric-ccenv:amd64-latest "/bin/sh -c 'GOPATH=…" About a minute ago Up About a minute relaxed_benz ```

MHBauer (Thu, 21 Feb 2019 21:01:59 GMT):
any idea what causes this to hang around osme times?

MHBauer (Thu, 21 Feb 2019 21:03:04 GMT):
so finnicky.

MHBauer (Thu, 21 Feb 2019 21:03:23 GMT):
wasn't that.

MHBauer (Thu, 21 Feb 2019 21:56:42 GMT):
I think the interrupt tests are in the wrong place.

MHBauer (Thu, 21 Feb 2019 21:59:00 GMT):
other than the fact that it won't run without having a fabric tot connect to :rolling_eyes:

braduf (Tue, 05 Mar 2019 00:04:59 GMT):
Has joined the channel.

bjwswang (Tue, 05 Mar 2019 06:43:40 GMT):
Has joined the channel.

klenik (Wed, 06 Mar 2019 11:25:14 GMT):
Has joined the channel.

lehors (Wed, 06 Mar 2019 18:06:20 GMT):
@MHBauer you might want to look at the discussion on Fabric's gerrit review policy: https://chat.hyperledger.org/channel/fabric-maintainers?msg=K4xWe7W42iXyghvdb

lehors (Wed, 06 Mar 2019 18:06:20 GMT):
@MHBauer @swetha you might want to look at the discussion on Fabric's gerrit review policy: https://chat.hyperledger.org/channel/fabric-maintainers?msg=K4xWe7W42iXyghvdb

lehors (Wed, 06 Mar 2019 18:07:03 GMT):
also: "Fabric-CA has recently moved from two +2 review policy to non-author code review (NACR) which requires one +2. "

lehors (Wed, 06 Mar 2019 18:08:29 GMT):
I think given the very small group of maintainers you have it would make sense to get a less restrictive policy

swetha (Wed, 06 Mar 2019 19:42:40 GMT):
@lehors That's interesting. I like the idea of NACR, and totally agree a less restrictive policy would be good for us, not to mention would reduce the bottleneck we are currently facing in terms of reviews

swetha (Wed, 06 Mar 2019 19:44:18 GMT):
@guoger what do you think? I know you have talked about a single +2 as well

guoger (Thu, 07 Mar 2019 00:21:44 GMT):
Yep, totally agree...

MHBauer (Thu, 07 Mar 2019 18:32:58 GMT):
3 & 4, I'll help werie

MHBauer (Thu, 07 Mar 2019 18:33:02 GMT):
review*

guoger (Fri, 08 Mar 2019 02:49:13 GMT):
docs merged with some comments

MHBauer (Fri, 08 Mar 2019 07:22:18 GMT):
comments filed as ticket?

MHBauer (Fri, 08 Mar 2019 07:22:23 GMT):
or on an existing ticket

guoger (Fri, 08 Mar 2019 10:17:58 GMT):
@MHBauer just on those merged CRs

Suma (Fri, 08 Mar 2019 14:49:41 GMT):
Has joined the channel.

swetha (Fri, 08 Mar 2019 19:08:58 GMT):
thanks @guoger !

Yogendrasri (Mon, 11 Mar 2019 14:04:39 GMT):
Has joined the channel.

Yogendrasri (Mon, 11 Mar 2019 14:05:16 GMT):
We are looking to create Ethereum ERC 20 tokens but within HL Fabric runtime. we have found that we need to use fab proxy to connect to Eth VM in HL Fabric env. And that there is a constraint of one user per fab proxy, This is a issue because we need to move tokens between users, and this means that if we need to create 5k users, which also implies that we need to create 5K Fab Proxies. is there any way fab proxy constraint can be managed/eliminated?

guoger (Mon, 11 Mar 2019 15:09:12 GMT):
It should be doable when offline signing is enabled in SDK. @swetha should be able to have a more detailed answer @Yogendrasri [ ](https://chat.hyperledger.org/channel/fabric-evm?msg=is2WAm9dJHhEcTACG)

guoger (Mon, 11 Mar 2019 15:10:07 GMT):
Basically user should be able to sign the tx with their own private key, and fab3 will simply forward the signed tx

swetha (Mon, 11 Mar 2019 20:54:07 GMT):
@Yogendrasri, Currently, as you said, we don't have the ability for fab3 to act as different users. We do want to support offline signing which would result in implemnting `eth_sendRawTransaction`. This way the transactions are formed and signed outside of fab3 and then can be sent in through a single fab3 regardless of the user. However our current blocker for that is that the Fabric Go SDK, which is the library we use to interact with the Fabric network, does not currently support that feature. Can you tell me more about how your network will look in terms of orgs, and users per org? And if fab3 were to support more than one user at a time, how would you divide out the users amongst the different fab3? In general, my reluctance of supporting multiple users is because fab3 becomes more of a centralized component in that design.

swetha (Mon, 11 Mar 2019 20:54:07 GMT):
@Yogendrasri, Currently, as you said, we don't have the ability for fab3 to act as different users. We do want to support offline signing which would result in implemnting `eth_sendRawTransaction`. This way the transactions are formed and signed outside of fab3 and then can be sent in through a single fab3 regardless of the user. However our current blocker for that is that the Fabric Go SDK, which is the library we use to interact with the Fabric network, does not currently support that feature. Can you tell me more about how your network will look in terms of orgs, and users per org? And if fab3 were to support more than one user at a time, how would you divide out the users amongst the different fab3? In general, my reluctance to supporting multiple users is because fab3 becomes more of a centralized component in that design.

swetha (Mon, 11 Mar 2019 20:54:07 GMT):
@Yogendrasri, Currently, as you said, we don't have the ability for fab3 to act as different users. We do want to support offline signing which would result in implemnting `eth_sendRawTransaction`. This way the transactions are formed and signed outside of fab3 and then can be sent in through a single fab3 regardless of the user. However our current blocker for that is that the Fabric Go SDK, which is the library we use to interact with the Fabric network, does not currently support that feature. Can you tell me more about how your network will look in terms of orgs, and users per org? And if fab3 were to support more than one user at a time, how would you divide out the users amongst the different fab3 instances? In general, my reluctance to supporting multiple users is because fab3 becomes more of a centralized component in that design.

KyunghoKim (Tue, 12 Mar 2019 03:08:44 GMT):
Has joined the channel.

Yogendrasri (Tue, 12 Mar 2019 12:10:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=pheLBmXm7Jb6frBwW) @swetha Thank you Swetha for your response

bh4rtp (Wed, 13 Mar 2019 00:42:41 GMT):
Has joined the channel.

MHBauer (Wed, 13 Mar 2019 02:54:05 GMT):
some time in the recent past we made a wiki page

MHBauer (Wed, 13 Mar 2019 02:54:24 GMT):
there hasn't been anything on it until today (I had thought I had posted something, but perhaps never saved)

MHBauer (Wed, 13 Mar 2019 02:54:25 GMT):
https://wiki.hyperledger.org/display/fabric/Fabric+Chaincode+EVM

MHBauer (Wed, 13 Mar 2019 02:54:45 GMT):
I'd like to pin it, but I don't think I have perms.

MHBauer (Wed, 13 Mar 2019 02:55:19 GMT):
As part of this, I'd like to solicitate the community to have a discussion on when we do releases.

MHBauer (Wed, 13 Mar 2019 02:55:45 GMT):
We made a 1.4 based release and then increased drastically the compatibility by updating burrow.

MHBauer (Wed, 13 Mar 2019 02:56:16 GMT):
I think we should make releases more often, and less tied to fabric releases.

MHBauer (Wed, 13 Mar 2019 02:56:33 GMT):
need to figure out a way to make a poll or something.

guoger (Wed, 13 Mar 2019 03:08:55 GMT):

guoger (Wed, 13 Mar 2019 03:09:13 GMT):
pinned for you. i don't have permission to promote you to be moderator though...

swetha (Wed, 13 Mar 2019 03:24:31 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=8DLFdMvwxT57Jz2SC) @MHBauer I like the quarterly approach. It doesn't necessarily need to be tied to fabric release as in we don't wait for them. It makes it easy for us to aim for features. I also don't think a monthly release is doable because of the time it takes to get patches in.

MHBauer (Wed, 13 Mar 2019 03:43:29 GMT):
@lehors ^the wiki we started. I'd also like to get your perspective on a 'community inclusion checklist' so we behave appropriately.

cbf (Wed, 13 Mar 2019 11:17:20 GMT):
IMO, we should strive for matching the quarterly fabric releases

cbf (Wed, 13 Mar 2019 11:17:45 GMT):
however, more frequent is also acceptable

MHBauer (Wed, 13 Mar 2019 18:09:17 GMT):
do we have a hyperledger docs type thing, or an etherpad? would be good to have everybody write down their opinion and try to make sense of it.

swetha (Wed, 13 Mar 2019 18:45:37 GMT):
Updated this patch to now be a burrow upgrade: https://gerrit.hyperledger.org/r/#/c/29565/

MHBauer (Wed, 13 Mar 2019 19:14:15 GMT):
sweet

MHBauer (Wed, 13 Mar 2019 19:14:34 GMT):
@swetha can I get a quick response on the getlogs comment?

MHBauer (Wed, 13 Mar 2019 19:14:54 GMT):
I added an earliest somewhere else, what are we thinking to have it there?

MHBauer (Wed, 13 Mar 2019 19:15:00 GMT):
doesn't matter to me, should be quick to add.

swetha (Wed, 13 Mar 2019 19:15:00 GMT):
the earliest paramter?

swetha (Wed, 13 Mar 2019 19:16:04 GMT):
In other one we add the earliest parameter but since we mock the blocks out i though it would be nice to add in earliest in the integration test so it tests all those pieces without any mocks

swetha (Wed, 13 Mar 2019 19:16:04 GMT):
In the other one we add the earliest parameter but since we mock the blocks out i though it would be nice to add in earliest in the integration test so it tests all those pieces without any mocks

swetha (Wed, 13 Mar 2019 19:16:04 GMT):
In the other one we add the earliest parameter but since we mock the blocks out i thoughy it would be nice to add in earliest in the integration test so it tests all those pieces without any mocks

swetha (Wed, 13 Mar 2019 19:16:04 GMT):
In the other one we add the earliest parameter but since we mock the blocks out i thought it would be nice to add in earliest in the integration test so it tests all those pieces without any mocks

swetha (Wed, 13 Mar 2019 19:17:17 GMT):
so it isn't about testing "earliest" more just verifying that we didn't make any assumptions that we shouldn't have on the block type

MHBauer (Wed, 13 Mar 2019 19:18:20 GMT):
eh? it's an integration test, how'd we mock the blocks?

MHBauer (Wed, 13 Mar 2019 19:18:26 GMT):
now I'm very concerned

swetha (Wed, 13 Mar 2019 19:18:43 GMT):
I thought the "earliest" was in a unit test not in the integration

swetha (Wed, 13 Mar 2019 19:18:50 GMT):
we mock blocks out in the unit test

MHBauer (Wed, 13 Mar 2019 19:18:55 GMT):
I commented it on it

MHBauer (Wed, 13 Mar 2019 19:19:04 GMT):
the usage

MHBauer (Wed, 13 Mar 2019 19:19:10 GMT):
twice, I think.

MHBauer (Wed, 13 Mar 2019 19:19:22 GMT):
hard to keep track of all these changes though

swetha (Wed, 13 Mar 2019 19:19:59 GMT):
yup, my bad yes didn't see the new comments

MHBauer (Wed, 13 Mar 2019 19:20:03 GMT):
only once

MHBauer (Wed, 13 Mar 2019 19:20:06 GMT):
https://gerrit.hyperledger.org/r/#/c/28949/29/integration/fab3/fab3_test.go@241 241

swetha (Wed, 13 Mar 2019 19:20:23 GMT):
i think we are fine then, ill respond on the patch too

MHBauer (Wed, 13 Mar 2019 19:20:34 GMT):
oh, left a debug in there, dang it.

MHBauer (Wed, 13 Mar 2019 19:20:42 GMT):
well, it only prints on failure, so....

swetha (Wed, 13 Mar 2019 19:20:47 GMT):
the Fprintln?

MHBauer (Wed, 13 Mar 2019 19:20:49 GMT):
:-D

swetha (Wed, 13 Mar 2019 19:20:55 GMT):
i thought that was intentional

MHBauer (Wed, 13 Mar 2019 19:20:59 GMT):
yes

MHBauer (Wed, 13 Mar 2019 19:21:01 GMT):
very intentional

swetha (Wed, 13 Mar 2019 19:21:09 GMT):
ill remember that for the future :P

MHBauer (Wed, 13 Mar 2019 19:21:21 GMT):
it's the one that got away

MHBauer (Wed, 13 Mar 2019 19:21:47 GMT):
I should make a shortcut for "fmt.Fprintln(GinkgoWriter, )" and have it leave the cursor after the comma

swetha (Wed, 13 Mar 2019 21:57:38 GMT):
@MHBauer just added some new comments to the minimum getLogs. I think we need to move where with do the genesis block test to avoid flaky tests

MHBauer (Wed, 13 Mar 2019 22:24:19 GMT):
ya, was worried about that in a different case, but it appears to be relevant here

MHBauer (Wed, 13 Mar 2019 22:24:26 GMT):
what's the flag for randomize all the things?

MHBauer (Wed, 13 Mar 2019 22:26:50 GMT):
any idea what causes ' cannot connect to Docker endpoint'

swetha (Wed, 13 Mar 2019 22:43:48 GMT):
where are you seeing that error?

swetha (Wed, 13 Mar 2019 22:44:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=NMFrdxjpNQ6G7oJjZ) @MHBauer `--randomizeAllSpecs`

swetha (Wed, 13 Mar 2019 22:44:46 GMT):
when tests run in ci, they get randomized through `scripts/run-integration-tests.sh`

MHBauer (Wed, 13 Mar 2019 23:44:48 GMT):
neat. I run that sometimes.

MHBauer (Thu, 14 Mar 2019 04:29:23 GMT):
@guoger on a merge spree tonight!

AhmedRebai (Thu, 14 Mar 2019 08:24:49 GMT):
Has joined the channel.

AhmedRebai (Thu, 14 Mar 2019 08:25:12 GMT):
Hi Guys what's the goal of this project ?

lehors (Thu, 14 Mar 2019 08:33:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=XiHE9RcaTFNAoxeE7) @AhmedRebai The goal is to enable one to use the Hyperledger Fabric permissioned blockchain platform to interact with Ethereum smart contracts written in an EVM compatible language such as Solidity or Vyper.

lehors (Thu, 14 Mar 2019 08:33:56 GMT):
see https://github.com/hyperledger/fabric-chaincode-evm/

AhmedRebai (Thu, 14 Mar 2019 08:34:24 GMT):
but what's the main advantages of this interaction ?

lehors (Thu, 14 Mar 2019 08:34:53 GMT):
you mean integration?

AhmedRebai (Thu, 14 Mar 2019 08:34:57 GMT):
we can use implement smart contract in chaincode for hyperldger-fabric and is running well

AhmedRebai (Thu, 14 Mar 2019 08:35:04 GMT):
yes integration !

lehors (Thu, 14 Mar 2019 08:35:25 GMT):
if you're already using fabric natively than you probably don't have a use for this

lehors (Thu, 14 Mar 2019 08:36:17 GMT):
this is really for people who started with ethereum and have developed smart contracts, clients, and skills they want to bring to a Fabric network

AhmedRebai (Thu, 14 Mar 2019 08:36:43 GMT):
can you tell me some use cases of this integration ?

lehors (Thu, 14 Mar 2019 08:37:12 GMT):
it is easy to start with Ethereum because there is a testnet anyone can use

lehors (Thu, 14 Mar 2019 08:37:35 GMT):
so many people start with Ethereum

hssanbenrhouma (Thu, 14 Mar 2019 08:37:56 GMT):
Has joined the channel.

lehors (Thu, 14 Mar 2019 08:38:05 GMT):
yet, they eventually realize it has limitations that makes it hardly suitable for production systems

AhmedRebai (Thu, 14 Mar 2019 08:38:11 GMT):
but it depends in the use case to implement the ethereuem technology or the hyperldger-fabric

lehors (Thu, 14 Mar 2019 08:38:44 GMT):
so, this integration can help them transition to Fabric

AhmedRebai (Thu, 14 Mar 2019 08:38:58 GMT):
for a junior developer having experience with Ethereuem smart contract and hyperledger-fabric

AhmedRebai (Thu, 14 Mar 2019 08:40:13 GMT):
so the goal of this integration it to make it easy for those who have started with Ethereuem

lehors (Thu, 14 Mar 2019 08:40:24 GMT):
correct

AhmedRebai (Thu, 14 Mar 2019 08:40:29 GMT):
to start with hyperledger ?

AhmedRebai (Thu, 14 Mar 2019 08:40:32 GMT):
;)

lehors (Thu, 14 Mar 2019 08:40:37 GMT):
hyperledger fabric

AhmedRebai (Thu, 14 Mar 2019 08:40:49 GMT):
yes hyeperledger fabric

lehors (Thu, 14 Mar 2019 08:40:50 GMT):
hyperledger is a consortium not a software

AhmedRebai (Thu, 14 Mar 2019 08:40:58 GMT):
yes yes i know :D

AhmedRebai (Thu, 14 Mar 2019 08:41:17 GMT):
but it's not ready yet for production mode

AhmedRebai (Thu, 14 Mar 2019 08:42:40 GMT):
i'm currently Blockchain developer intern , we are participating in a bootcamp to learn the blockchain technology (from bitcoin , ethereuem and now Hyperledger-fabric )

AhmedRebai (Thu, 14 Mar 2019 08:43:35 GMT):
the task of this week is to explore this repository , trying to make it working and build a use case based in fabric-chaincode-evm

lehors (Thu, 14 Mar 2019 08:44:26 GMT):
so, if you have already developed some solidity contract and fab3 client you could try to run it on a fabric network with this

lehors (Thu, 14 Mar 2019 08:44:40 GMT):
there are some restrictions though

hssanbenrhouma (Thu, 14 Mar 2019 08:44:47 GMT):
@lehors one question : in medical chain project, they used both hyperledger fabric and ethereum hyperledger-fabric for private blockchain (doctors, pharmacies and hospitals) and the ethereum public blockchain for patients interactions with the private network is that have any relation with borrow project (fabric evm) ?

lehors (Thu, 14 Mar 2019 08:44:49 GMT):
it won't work if your contract is payable

lehors (Thu, 14 Mar 2019 08:44:57 GMT):
because there is no Ether in Fabric

lehors (Thu, 14 Mar 2019 08:45:08 GMT):
burrow

lehors (Thu, 14 Mar 2019 08:45:14 GMT):
yes, it very much does

lehors (Thu, 14 Mar 2019 08:45:24 GMT):
this integration leverage's the burrow evm

lehors (Thu, 14 Mar 2019 08:45:24 GMT):
this integration leverages the burrow evm

lehors (Thu, 14 Mar 2019 08:46:01 GMT):
essentiallly it installs the burrow evm as a fabric chaincode

AhmedRebai (Thu, 14 Mar 2019 08:51:46 GMT):
so the network is implemented with fabric and the smart contract with Solidity running in EVm ? to interact with Ethereuem smart contract in hyperldger environment we should use Fab3 client ?

guoger (Thu, 14 Mar 2019 09:05:23 GMT):
@AhmedRebai you could use fabric sdk or cli as well. Fab3 implements a subset of JSON RPC, so you can use web3.js lib, as well as some other tooling such as Remix. Truffle is WIP

lehors (Thu, 14 Mar 2019 09:43:24 GMT):
@AhmedRebai if you already developed a web3 client it would be interesting for your project to try and reuse it by connecting to the fab3 proxy

lehors (Thu, 14 Mar 2019 09:44:53 GMT):
the flow becomes web3 client -> fab3 proxy -> fabric peer -> evm chaincode -> evm burrow -> ethereum contract

lehors (Thu, 14 Mar 2019 09:44:53 GMT):
the flow becomes web3 client -> fab3 proxy -> fabric peer -> evm chaincode -> burrow evm -> ethereum contract

lehors (Thu, 14 Mar 2019 09:45:50 GMT):
the two ends should be reusable as is

lehors (Thu, 14 Mar 2019 09:46:12 GMT):
as if they were running on an Ethereum network

AhmedRebai (Thu, 14 Mar 2019 10:17:08 GMT):
sorry i'm having an issue while trying to install Fab3 client

AhmedRebai (Thu, 14 Mar 2019 10:21:27 GMT):

error.png

HELASOUISSI (Thu, 14 Mar 2019 14:08:02 GMT):
Has joined the channel.

HELASOUISSI (Thu, 14 Mar 2019 14:12:34 GMT):
hello what is the main file of this project that runs the netwrok and the containers ?

HELASOUISSI (Thu, 14 Mar 2019 14:18:01 GMT):
because i'm having an issue while running this command !

HELASOUISSI (Thu, 14 Mar 2019 14:18:16 GMT):

Capture du 2019-03-14 15-17-18.png

HELASOUISSI (Thu, 14 Mar 2019 14:18:44 GMT):
peer command was not found !

lehors (Thu, 14 Mar 2019 14:52:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=2GcSk3YEMzkizSW3n) @HELASOUISSI the peer command is part of Fabric

lehors (Thu, 14 Mar 2019 14:53:10 GMT):
you can download the binary following the fabric installation instructions

lehors (Thu, 14 Mar 2019 14:54:19 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/install.html

AhmedRebai (Thu, 14 Mar 2019 16:20:44 GMT):
hi @lehors what's the utility of Fab3 ?

lehors (Thu, 14 Mar 2019 16:24:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=vdW8cQ4z6NTS5fMrm) @AhmedRebai fab3 is a proxy, it allows a web3 client to connect to a fabric network

lehors (Thu, 14 Mar 2019 16:24:27 GMT):
without modification

lehors (Thu, 14 Mar 2019 16:24:53 GMT):
for the web3 client, it is as if it is connected to ethereum

AhmedRebai (Thu, 14 Mar 2019 16:27:16 GMT):
so my data is stored in ethereuem smart contract ?

AhmedRebai (Thu, 14 Mar 2019 16:27:30 GMT):
it's public or deployed in hyperledger network ?

swetha (Thu, 14 Mar 2019 17:19:46 GMT):
@AhmedRebai Fab3 is just a proxy. Currently it is stateless. When you use it, it will connect to the Fabric network of your choosing. So all the data and contracts will be deployed to that network you connected Fab3 to.

swetha (Thu, 14 Mar 2019 17:21:03 GMT):
Were you able to build fab3? The error you sent above is because your the fabric-chaincode-evm is not in the gopath

MarioPissardo (Thu, 14 Mar 2019 22:31:24 GMT):
Has joined the channel.

AhmedRebai (Fri, 15 Mar 2019 09:39:47 GMT):
thanks @swetha

raj_shekhar (Mon, 18 Mar 2019 05:52:44 GMT):
Has joined the channel.

fastchain (Mon, 18 Mar 2019 07:49:22 GMT):
Has joined the channel.

fastchain (Mon, 18 Mar 2019 07:53:00 GMT):
Hello everyone! Which project from https://github.com/hyperledger/fabric-chaincode-evm and https://github.com/hyperledger/burrow is the most mature? Which one is the bect to run Solidity contracts.

silasdavis (Mon, 18 Mar 2019 09:33:03 GMT):
fabric-chaincode-evm uses the Burrow code as a library so in terms of execution you should see parity - modulo the version of Burrow being used - fabric-evm is due an upgrade shortly, however fabric-chaincode-evm has fab3 (coming to Burrow too in the medium term) which means you can use web3 tooling. The biggest difference with Burrow is that it uses Tendermint consensus and operationally is a bit simpler (it's a single Go binary) because it doesn't have the notion of different chaincode.

klenik (Mon, 18 Mar 2019 10:07:11 GMT):
Hi All! When [interacting with a deployed smart contract](https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md#interacting-with-a-deployed-contract), what is the standard way to derive the function hashes? And are there any (syntactic) constraints I need to consider when passing multiple arguments to a smart contract function? If these are implementation-independent EVM rules, just point me to the appropriate docs, thanks :)

fastchain (Mon, 18 Mar 2019 10:12:22 GMT):
@silasdavis thank you!

klenik (Mon, 18 Mar 2019 14:26:58 GMT):
found the ABI encoding spec and related helpful libs in the meantime

MHBauer (Mon, 18 Mar 2019 18:00:17 GMT):
small one ready to merge https://gerrit.hyperledger.org/r/#/c/30069/

leowu (Mon, 18 Mar 2019 20:12:12 GMT):
Has joined the channel.

leowu (Mon, 18 Mar 2019 20:12:16 GMT):
Hi everyone. I am new into Hyperledger burrow. I have a question about it. So I know that for burrow we are using Smart Contract instead of Chaincode in the Burrow EVM. So is that possible that we can run the Chaincode and the Solidity Smart Contract Simultaneously?

leowu (Mon, 18 Mar 2019 20:12:33 GMT):
I have successfully installed and run the fabric-chainode-evm and the vote-hyperledger-ethereum and the web3-fabric-voting-dapp. But I just wondering that is it possible I can deploy the Chaincode instead and run Chaincode and Smart Contract simultaneously.

MHBauer (Mon, 18 Mar 2019 20:18:57 GMT):
burrow is a different project. We use the burrow EVM as a chaincode. solidity compiled to evm byte code runs in the chaincode. I don't understan dthe last question.

noyonthe1 (Tue, 19 Mar 2019 05:47:32 GMT):
Has joined the channel.

AhmedRebai (Tue, 19 Mar 2019 09:04:10 GMT):
Hi, I Have a question, I just deployed my hyper ledger fabric network and fixing the evm instantiation, my smart contract is implemented with ethereuem and deployed, but how to set which channel should we connect to interact with the smart contract? how the permission advantage is implemented?

leowu (Tue, 19 Mar 2019 13:35:31 GMT):
@MHBauer Thx. What I am asking is Can we deploy two Smart Contract (ex: one is Go-lang chaincode and the other one is Solidity Smart Contract) at the same time and let them interact with each other? Is it possible?

leowu (Tue, 19 Mar 2019 14:53:46 GMT):
For example, I created the web3-fabric-voting-dapp which I used the vote.sol as my Smart Contract. So right now I want to deploy another Chaincode written in Go-lang and I want to Get the result of the voting. Just something like interacting with two smart contracts but in different language. Is that possible?

raphaelbenoit (Tue, 19 Mar 2019 16:35:21 GMT):
Has joined the channel.

klenik (Tue, 19 Mar 2019 17:23:43 GMT):
@MHBauer When deploying a bytecode (compiled from Solidity with solc-js), how can I "pass" the constructor arguments? Evmcc forwards the bytecode both as code and input. Did I miss something on the client-side?

MHBauer (Tue, 19 Mar 2019 17:35:14 GMT):
EVM cc isn't configured to do anything outside of it's domain.

MHBauer (Tue, 19 Mar 2019 17:36:16 GMT):
an external chaincode should be able to access the data if it's on the same channel, but you'd have to know where the data is stored and how to parse it. We've not made any plans for that to be easy at the moment.

MHBauer (Tue, 19 Mar 2019 17:37:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=RrRefwuwegtGmzD7Y) @AhmedRebai deploying the evmcc must have been done on a channel. The fab3 proxy takes an sdk configuration for the details on how to connect, as well as flags speciying the ccname and channel name.

MHBauer (Tue, 19 Mar 2019 17:38:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=q9LKJ9uBpdPqAAQqW) @klenik Can you send me an example contract? I'm not sure how the evmcc could be involved here.

klenik (Tue, 19 Mar 2019 18:13:21 GMT):
@MHBauer The dummy contract: ``` pragma solidity ^0.4.24; contract Abs { int public dummyValue; constructor(int y) public { dummyValue = y; } function abs(int x) public pure returns (int) { int y = x; if (y < 0) y *= -1; assert(y >= 0); return y; } } ``` If I compile it, I get a `bytecode`, that I can [pass to evmcc](https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md#deploying-a-contract). Then [this line in evmcc](https://github.com/hyperledger/fabric-chaincode-evm/blob/125e0855da3ba2600bf0456317fca5eaa232db7f/evmcc/evmcc.go#L133) passes this `bytecode` to the Burrow EVM both as `code` and `input`. Where can I squash in my dummy integer parameter? Should it be part of the `bytecode` somehow?

MHBauer (Tue, 19 Mar 2019 18:36:33 GMT):
gonna try and run it, may have a newtest case.

MHBauer (Tue, 19 Mar 2019 18:40:56 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=KSW6GPZm366awTk3b) @klenik sounds like you're interacting with the CC directly, and not through fab3?

MHBauer (Tue, 19 Mar 2019 18:54:02 GMT):
If I use remix attached to fab3, it shows a constructor argument when I deploy.

MHBauer (Tue, 19 Mar 2019 19:10:07 GMT):
d'ise

MHBauer (Tue, 19 Mar 2019 19:10:14 GMT):
but yea, it doesn't seem to work correctly to me.

MHBauer (Tue, 19 Mar 2019 19:11:37 GMT):
I'm going to make a jira ticket.

MHBauer (Tue, 19 Mar 2019 19:17:44 GMT):
nope, nevermind, I'm a dummy.

MHBauer (Tue, 19 Mar 2019 19:17:45 GMT):
works fine.

MHBauer (Tue, 19 Mar 2019 19:18:06 GMT):
turns out every negative number is less than a positive number, who knew?

MHBauer (Tue, 19 Mar 2019 19:20:37 GMT):
I can make a short video if it would help, but I modified the contract a little bit to make sure that the value was present.

MHBauer (Tue, 19 Mar 2019 19:20:47 GMT):
``` ```

MHBauer (Tue, 19 Mar 2019 19:20:47 GMT):
``` pragma solidity ^0.5; contract Abs { int public dummyValue; constructor(int y) public { dummyValue = y; } function abs(int x) public view returns (int) { int y = x; if (y < dummyValue) { y *= -1; } return y; } ```

MHBauer (Tue, 19 Mar 2019 19:21:50 GMT):
probably could have just returned dummyValue directly, but oh well.

klenik (Tue, 19 Mar 2019 19:22:20 GMT):
@MHBauer Yep, I'm interacting with evmcc directly through HL Caliper (adding the fabric-evm support to it right now). So if it works through Remix->fab3, then the value of `y` must be encoded in the `bytecode` somehow, since the CC doesn't receive additional arguments

MHBauer (Tue, 19 Mar 2019 19:22:50 GMT):
caliper is the perf thingy?

klenik (Tue, 19 Mar 2019 19:24:35 GMT):
Yes. And since it has a solid Fabric support already, adding Solidity (or any EVM bytecode) support through your CC is quite straightforward, except for this constructor part. But I think it's because of my lack of EVM knowledge

MHBauer (Tue, 19 Mar 2019 19:25:17 GMT):
yes, well we have some idiosyncracies specific to the domain

MHBauer (Tue, 19 Mar 2019 19:25:24 GMT):
I need to go give a docker presentation.

MHBauer (Tue, 19 Mar 2019 19:25:33 GMT):
we should talk. I need to do some perf testing.

klenik (Tue, 19 Mar 2019 19:25:55 GMT):
:thumbsup: DM me any time

MHBauer (Tue, 19 Mar 2019 21:17:36 GMT):
@klenik I added some debug logs, and it looks like it's appended on the end.

MHBauer (Tue, 19 Mar 2019 21:17:48 GMT):
`0x608060405234801561001057600080fd5b506040516020806101078339810180604052602081101561003057600080fd5b8101908080519060200190929190505050806000819055505060b0806100576000396000f3fe6080604052348015600f57600080fd5b506004361060325760003560e01c806370469c26146037578063fdae7476146053575b600080fd5b603d606f565b6040518082815260200191505060405180910390f35b60596075565b6040518082815260200191505060405180910390f35b60005481565b6000806000549050809150509056fea165627a7a723058204266cdf6237856aca030627567b9d04d635f1d0a0ec89f5d3e032f9629943d2700290000000000000000000000000000000000000000000000000000000000000063`

MHBauer (Tue, 19 Mar 2019 21:18:03 GMT):
see the bunch of 00 with 63 at the end? that's the argument

MHBauer (Tue, 19 Mar 2019 21:20:16 GMT):
and if I run the compiler, I get the same output

MHBauer (Tue, 19 Mar 2019 21:20:25 GMT):
``` docker run --rm -i ethereum/solc:0.5.6 --combined-json bin - < Constructor.sol | jq . { "contracts": { ":Abs": { "bin": "608060405234801561001057600080fd5b506040516020806101078339810180604052602081101561003057600080fd5b8101908080519060200190929190505050806000819055505060b0806100576000396000f3fe6080604052348015600f57600080fd5b506004361060325760003560e01c806370469c26146037578063fdae7476146053575b600080fd5b603d606f565b6040518082815260200191505060405180910390f35b60596075565b6040518082815260200191505060405180910390f35b60005481565b6000806000549050809150509056fea165627a7a72305820875f1f67a2d0ee19e2841694206eb2a2a9ac337955d41c4ac87ef92af3b626810029" } }, "version": "0.5.6+commit.b259423e.Linux.g++" } ``` just without the appended argument

klenik (Tue, 19 Mar 2019 21:29:10 GMT):
@MHBauer So I just need to encode the argument list according to the EVM spec (just like with a normal function call) and simply append it at the end? I'll give it a try. Thanks for the quick help!

MHBauer (Tue, 19 Mar 2019 21:46:52 GMT):
yup, looks like that when I send it.

MHBauer (Tue, 19 Mar 2019 21:47:04 GMT):
all we do is take the arg and shove it directly into the evmcc

MHBauer (Tue, 19 Mar 2019 21:47:16 GMT):
no nothing, maybe a 0x on the front.

MHBauer (Tue, 19 Mar 2019 22:21:24 GMT):
@guoger https://gerrit.hyperledger.org/r/#/c/28949/ nits addressed I believe.

guoger (Tue, 19 Mar 2019 23:05:48 GMT):
Will look into it today @MHBauer [ ](https://chat.hyperledger.org/channel/fabric-evm?msg=2wi54Z346yufrsust)

MHBauer (Tue, 19 Mar 2019 23:17:11 GMT):
thankee, hope I didn't wake you

seokm0 (Wed, 20 Mar 2019 02:27:41 GMT):
Has joined the channel.

klenik (Wed, 20 Mar 2019 13:50:26 GMT):
@MHBauer When I try to instantiate the evmcc in a `fabric-peer` container, the dependencies are not available by default. What's the easiest way to make the `vendor` directory available in the container? Can I install it together with the evmcc? Or should I mount the vendor dir into the container's gopath?

klenik (Wed, 20 Mar 2019 15:19:24 GMT):
@MHBauer Currently I try to `dep ensure` locally based on the GoPkg.lock in the fabric-evm repo then install evmcc with the vendor dir. Is there an easier approach?

MHBauer (Wed, 20 Mar 2019 18:52:18 GMT):
I mount the whole project at the gopath location

MHBauer (Wed, 20 Mar 2019 18:52:22 GMT):
` - ~/go/src/github.com/hyperledger/fabric-chaincode-evm:/opt/gopath/src/github.com/hyperledger/fabric-chaincode-evm `

MHBauer (Wed, 20 Mar 2019 18:52:38 GMT):
@klenik

klenik (Wed, 20 Mar 2019 19:30:19 GMT):
@MHBauer That would work, but I'm trying to add evmcc to the Caliper examples, so I need it to be as self-contained as possible. So I'm trying to figure out the dependencies of evmcc minus the fabric deps, since they're present in the peer image. If you have this list ready, don't hold it back :)

MHBauer (Wed, 20 Mar 2019 19:41:16 GMT):
I don't understand.

MHBauer (Wed, 20 Mar 2019 19:43:41 GMT):
yes, it depends on fabric

MHBauer (Wed, 20 Mar 2019 19:44:14 GMT):
@klenik have you tried `go list`?

MHBauer (Wed, 20 Mar 2019 19:47:00 GMT):
@klenik https://gist.github.com/MHBauer/071f9d26f002ddadbee0a95b608f1f55 does this help?

MHBauer (Wed, 20 Mar 2019 19:47:26 GMT):
otherwise, I'm not sure I understand the issue of what you are trying to do.

klenik (Wed, 20 Mar 2019 20:08:46 GMT):
@MHBauer I'd like to install&instantiate evmcc through the Fabric SDK. My current solution is to copy the repo's vendor folder plus its own packages in the client's chaincode folder: ``` evmcc/ - vendor/ # repo's vendor content + event, eventmanager and statemanager dirs in github.com/hyperledger/fabric-chaincode-evm - evmcc.go ``` So the cc is installed with its dependencies (and this is how it should be). But his results in a 30+MB vendor folder, and I think/hope most of it comes from the vendored fabric deps, which are present in the peer image, so I'd like to remove those.

klenik (Wed, 20 Mar 2019 20:08:46 GMT):
@MHBauer I'd like to install&instantiate evmcc through the Fabric SDK. My current solution is to copy the repo's vendor folder plus its own packages in the client's chaincode folder: ``` evmcc/ - vendor/ # repo's vendor content + event, eventmanager and statemanager dirs in github.com/hyperledger/fabric-chaincode-evm - evmcc.go ``` So the cc is installed with its dependencies (and this is how it should be). But this results in a 30+MB vendor folder, and I think/hope most of it comes from the vendored fabric deps, which are present in the peer image, so I'd like to remove those.

MHBauer (Wed, 20 Mar 2019 20:10:01 GMT):
sounds like you're rearranging the project.

MHBauer (Wed, 20 Mar 2019 20:10:09 GMT):
not sure how to help you there.

klenik (Wed, 20 Mar 2019 20:12:09 GMT):
unless you know a quick way to remove the **fabric-only** dependencies, this'll be a manual labour from my part :/

MHBauer (Wed, 20 Mar 2019 20:13:18 GMT):
I blame go.

MHBauer (Wed, 20 Mar 2019 20:13:44 GMT):
a lot of it looks like golang.org/x/text and golang.org/x/sys

MHBauer (Wed, 20 Mar 2019 20:14:38 GMT):
the other half is a mix of stuff under github, only about 5.8m is hyperledger.

MHBauer (Wed, 20 Mar 2019 20:15:39 GMT):
not the largest vendor folder I've seen, by far, so I'm trying to help, but I still don't understand the real problem you're trying to solve.

klenik (Wed, 20 Mar 2019 20:26:30 GMT):
From a Caliper example point-of-view: I'd like to include evmcc as a sample chaincode (plus some solidity contracts), but committing its 30+MB dependencies is a bit extreme. Users cloning the Caliper repo would not like me :) (30MB for EVM support is awesome, but putting it in the Caliper repo is brrrr). It works for now on my dev fork, I'm far from merging so I don't need to come up with a more lightweight solution right now. But any thoughts on this topic (~What are the still required dependencies of evmcc, given that the fabric deps are available) is appreciated.

MHBauer (Wed, 20 Mar 2019 20:28:23 GMT):
what are the fabric deps exactly? we can diff the two lists

MHBauer (Wed, 20 Mar 2019 20:28:33 GMT):
also diff against the deps of fab3

MHBauer (Wed, 20 Mar 2019 20:28:46 GMT):
want to exclude the fab3 deps,

MHBauer (Wed, 20 Mar 2019 20:28:52 GMT):
along with the fabric deps.

MHBauer (Wed, 20 Mar 2019 20:34:04 GMT):
it's not going to be small, it's going to be emvmcc -> burrow -> a bunch of stuff.

klenik (Wed, 20 Mar 2019 20:38:26 GMT):
Fabric's vendor folder is almost 30MB, and those are available in the peer image. So basically I should do `{fabric-chaincode-evm vendor}\({fabric-chaincode-evm vendor} intersect {fabric vendor})`. Hopefully that would work

gWOLF3 (Thu, 21 Mar 2019 18:14:14 GMT):
Has joined the channel.

gWOLF3 (Thu, 21 Mar 2019 18:16:18 GMT):
hey guys, n00b question, whats the difference between this channel and #burrow? I though burrow was hyperledger fabric's EVM implementation. Or is it more abstract from fabric?

Khaled.MH (Sun, 24 Mar 2019 22:27:07 GMT):
Has joined the channel.

yanli133 (Mon, 25 Mar 2019 06:53:44 GMT):
Has joined the channel.

MHBauer (Tue, 26 Mar 2019 04:47:39 GMT):
https://gerrit.hyperledger.org/r/#/c/30396/ is tiny change

MHBauer (Tue, 26 Mar 2019 04:47:51 GMT):
https://gerrit.hyperledger.org/r/#/c/29565/ is big but good.

cbf (Tue, 26 Mar 2019 10:25:35 GMT):
I see a new tendermint/crypto but no license

cbf (Tue, 26 Mar 2019 10:27:47 GMT):
the repo does have the BSD with the go authors copyright

cbf (Tue, 26 Mar 2019 10:27:47 GMT):
the repo does have the BSD with the go authors copyright LICENSE file

swetha (Tue, 26 Mar 2019 17:18:19 GMT):
I don't think the tendermint license file got updated as part of the burrow update.

MHBauer (Tue, 26 Mar 2019 18:23:37 GMT):
thanks for cleaning up after my jiras guys

MHBauer (Tue, 26 Mar 2019 18:24:01 GMT):
is there a way we can work towards automating that?

MHBauer (Tue, 26 Mar 2019 18:25:47 GMT):
is there a way to encode a version-ish into the chaincode itself? I would find it useful to know what version/pr I'm running in my environment.

swetha (Tue, 26 Mar 2019 21:05:20 GMT):
there is a version that is connected to the chaincode that is running. but that is user provided at the time of installation and wouldn't necessarily correlate to the build

MHBauer (Tue, 26 Mar 2019 21:28:59 GMT):
yea, I want a software revision, not a version

guoger (Wed, 27 Mar 2019 16:17:59 GMT):
@swetha do we know how can `BLOCKHASH` opcode be invoked?

swetha (Wed, 27 Mar 2019 16:18:24 GMT):
I was just looking into that

guoger (Wed, 27 Mar 2019 16:18:31 GMT):
@MHBauer i'll get to your in-review CR tomorrow...

swetha (Wed, 27 Mar 2019 16:18:50 GMT):
i think it is similar to the sender variable

swetha (Wed, 27 Mar 2019 16:19:11 GMT):
https://solidity.readthedocs.io/en/v0.4.24/units-and-global-variables.html#special-variables-and-functions

guoger (Wed, 27 Mar 2019 16:22:13 GMT):
https://medium.com/coinmonks/is-block-blockhash-block-number-1-okay-14a28e40cc4b

guoger (Wed, 27 Mar 2019 16:22:33 GMT):
i fear this func is used sometimes to generate random number

guoger (Wed, 27 Mar 2019 16:24:22 GMT):
we could of course return the actual block hash, with a limitation that *current block hash* is not available

swetha (Wed, 27 Mar 2019 16:30:17 GMT):
I don't think we have access to that from the stub

swetha (Wed, 27 Mar 2019 16:30:28 GMT):
i guess we could do an invoke chaincode

swetha (Wed, 27 Mar 2019 16:30:31 GMT):
and get the ledger info?

swetha (Wed, 27 Mar 2019 16:32:00 GMT):
Though at the same time I think we are opening ourselves up for the possibility that transactions won't get endorsed because if the peers get new blocks and endorsement is done at different times, the block hash can be different

guoger (Wed, 27 Mar 2019 16:38:56 GMT):
Can we probably examine what this func is mostly used for? We could also say this should always take static argument, instead using a relative number, such as last block - 1. I also think we should merge yours now and revisit

swetha (Wed, 27 Mar 2019 16:46:09 GMT):
Okay i will make a change to improve the comments and add a note in the README as a limitation for right now. And we can look more into what we should be returning here

MHBauer (Wed, 27 Mar 2019 17:02:00 GMT):
what's all the attention on blockhash about?

swetha (Wed, 27 Mar 2019 17:36:38 GMT):
about the stub we added in for block hash

MHBauer (Wed, 27 Mar 2019 17:47:57 GMT):
oh, the panic is tied to an opcode?

swetha (Wed, 27 Mar 2019 17:54:09 GMT):
yup

MHBauer (Wed, 27 Mar 2019 17:57:38 GMT):
that's super bizarre now

MHBauer (Wed, 27 Mar 2019 17:57:44 GMT):
now I'm concerned again, okay

MHBauer (Wed, 27 Mar 2019 17:57:55 GMT):
I think we need a FAQ section on our intern proposal.

MHBauer (Wed, 27 Mar 2019 17:58:13 GMT):
or a link to our wiki page. something less formal.

MHBauer (Wed, 27 Mar 2019 18:25:19 GMT):
@swetha added some test cases to show handling of empty addresses

swetha (Wed, 27 Mar 2019 18:26:13 GMT):
cool, will take a look in a bit

MHBauer (Wed, 27 Mar 2019 18:29:27 GMT):
and now the error index as well

swetha (Wed, 27 Mar 2019 18:44:55 GMT):
So in regards to the blockhash. I did a little investigating. I am not clear on how we error if asked for a block that hasn't been created yet. But the idea is that the blockhash is queried on a certain block number. We could implement that and add a note stating to be careful of querying for a block number that hasn't been created yet or the latest block as that will either error or can cause discrepencies between the generated read and write sets. If that seems like a reasonable approach I can add that change in the burrow update now. Or I can add it in a subsequent jira/patch which gives us more time to figure out our options

swetha (Wed, 27 Mar 2019 18:45:08 GMT):
@MHBauer @guoger ^^

MHBauer (Wed, 27 Mar 2019 18:46:11 GMT):
I'd want a test case to run both before and after the change.

MHBauer (Wed, 27 Mar 2019 18:46:15 GMT):
As it is, I'm fine with it.

MHBauer (Wed, 27 Mar 2019 18:46:24 GMT):
we'll hear about it if we break someone.

swetha (Wed, 27 Mar 2019 18:47:31 GMT):
Yes, I will definitely be adding tests about the blockhash. more concerned about what is the actual behavior we want from the blockhash

swetha (Wed, 27 Mar 2019 18:48:00 GMT):
and whether we want it in the current patch or in a subsequent one, because it will make this patch larger

swetha (Wed, 27 Mar 2019 18:48:06 GMT):
it is not a small addition

MHBauer (Wed, 27 Mar 2019 18:48:16 GMT):
sounds like it gets a number and returns the hash of that number

MHBauer (Wed, 27 Mar 2019 18:48:23 GMT):
very straightforward.

MHBauer (Wed, 27 Mar 2019 18:48:33 GMT):
now

swetha (Wed, 27 Mar 2019 18:48:38 GMT):
burrow doesn't give us a way to error

MHBauer (Wed, 27 Mar 2019 18:48:41 GMT):
if you ask for a block in the future

MHBauer (Wed, 27 Mar 2019 18:49:08 GMT):
I would have to assume that the evm enforces that, otherwise it seems like a grievous oversight

MHBauer (Wed, 27 Mar 2019 18:49:35 GMT):
or we return some tombstone,

MHBauer (Wed, 27 Mar 2019 18:49:45 GMT):
so, again, I need more understanding ofhow that function is used.

MHBauer (Wed, 27 Mar 2019 18:49:56 GMT):
the more I learn, the less it seems I know.

swetha (Wed, 27 Mar 2019 19:00:03 GMT):
I am going to say lets review the current burrow update as is with the panic. I've added a note in the readme saying that blockhash is not supported. The blockhash change I will make in another patch/jira. There are still a few open questions in my mind like the error cases, and also whether we have to be concerned with permissioning in terms of chaincode invoking other chaincodes etc

MHBauer (Wed, 27 Mar 2019 19:00:19 GMT):
:+1:

MHBauer (Wed, 27 Mar 2019 19:19:34 GMT):
topic filters should be closer now given feedback on addresses

MHBauer (Thu, 28 Mar 2019 00:27:29 GMT):
we need to talk about how the evmcc stuff will conflict if there's a couple in the same channel.

guoger (Thu, 28 Mar 2019 10:00:09 GMT):
@swetha merged your CR with a [minor comment](https://gerrit.hyperledger.org/r/c/29565/7/README.md#77)

guoger (Thu, 28 Mar 2019 10:58:51 GMT):
@MHBauer when i run `ginkgo` in types pkg for https://gerrit.hyperledger.org/r/c/29095/, it says no tests found, and i need to run `ginkgo bootstrap` there.

MHBauer (Thu, 28 Mar 2019 11:19:33 GMT):
what's that do?

MHBauer (Thu, 28 Mar 2019 11:21:40 GMT):
I've never ginkgo'd before.

MHBauer (Thu, 28 Mar 2019 11:22:54 GMT):
It's weird, if I were to make a matric, (and I should).

guoger (Thu, 28 Mar 2019 11:30:05 GMT):
you wake up at a very weird time :joy:

guoger (Thu, 28 Mar 2019 11:31:06 GMT):
how do you run UT for types pkg?

swetha (Thu, 28 Mar 2019 16:11:21 GMT):
he needs to add a suite file in types and change this line to so that the types package is looked at

swetha (Thu, 28 Mar 2019 16:11:21 GMT):
he needs to add a suite file in types and change this line: https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Makefile#L29 to so that the types package is looked at

swetha (Thu, 28 Mar 2019 16:13:34 GMT):
@MHBauer ginkgo bootstrap just creates the suite file for the test. It takes care of all file creation and syntax

swetha (Thu, 28 Mar 2019 16:13:34 GMT):
@MHBauer ginkgo bootstrap just creates the suite file for the test. It takes care of all file creation and syntax. Also the piece that connects ginkgo to go test

MHBauer (Thu, 28 Mar 2019 17:27:15 GMT):
what

MHBauer (Thu, 28 Mar 2019 17:27:42 GMT):
I'm fixing that, that's ridiculous. We have computers.

MHBauer (Thu, 28 Mar 2019 18:13:20 GMT):
https://gerrit.hyperledger.org/r/#/c/30505/ okay

MHBauer (Thu, 28 Mar 2019 18:13:30 GMT):
that's the fix, merge that real quick and we can move on

MHBauer (Thu, 28 Mar 2019 18:15:49 GMT):
@swetha

swetha (Thu, 28 Mar 2019 18:20:25 GMT):
@MHBauer reviewing, don't agree with all of them

swetha (Thu, 28 Mar 2019 18:20:37 GMT):
particularly adding -cover

MHBauer (Thu, 28 Mar 2019 18:21:42 GMT):
why not?

swetha (Thu, 28 Mar 2019 18:22:41 GMT):
because i don't think thats a good mesaure of a test suite

swetha (Thu, 28 Mar 2019 18:22:51 GMT):
if someone is interested they can run themselves

swetha (Thu, 28 Mar 2019 18:22:51 GMT):
if someone is interested they can run it themselves

MHBauer (Thu, 28 Mar 2019 18:23:42 GMT):
what do you mean?

MHBauer (Thu, 28 Mar 2019 18:24:03 GMT):
I find it useful at a glance to know if my changes are changing thing.

MHBauer (Thu, 28 Mar 2019 18:30:33 GMT):
I'm not tied to `-p` that was only done in the integraion tests I think now.

swetha (Thu, 28 Mar 2019 18:31:59 GMT):
the `-p` should work, but yes the integration tests should work with parallel i think. but since they interact with the same environment in fab3 not sure what the consequences would be to enable parallel on integration tests. something to investigate

swetha (Thu, 28 Mar 2019 18:32:33 GMT):
cover, i think is find if you want to use it locally. but the second we make it part of the unit test target we are tagging are suites with that number and i don't think that is a good thing

swetha (Thu, 28 Mar 2019 18:32:33 GMT):
cover, i think is fine if you want to use it locally. but the second we make it part of the unit test target we are tagging are suites with that number and i don't think that is a good thing

swetha (Thu, 28 Mar 2019 18:32:33 GMT):
cover, i think is fine if you want to use it locally. but when we make it part of the unit test target we are tagging are suites with that number and i don't think that is a good thing

swetha (Thu, 28 Mar 2019 18:32:33 GMT):
cover, i think is fine if you want to use it locally. but when we make it part of the unit test target we are tagging our suites with that number and i don't think that is a good thing

MHBauer (Thu, 28 Mar 2019 18:33:19 GMT):
tagging?

swetha (Thu, 28 Mar 2019 18:33:28 GMT):
implicitly tagging

MHBauer (Thu, 28 Mar 2019 18:33:35 GMT):
I don't understand

swetha (Thu, 28 Mar 2019 18:33:58 GMT):
i don't want something like fab3 suite -> 50% coverage

swetha (Thu, 28 Mar 2019 18:34:08 GMT):
we aren't at 50%, but just as an example

swetha (Thu, 28 Mar 2019 18:34:30 GMT):
It also gives an impression that is a number we are care about and work to improve which we dont

MHBauer (Thu, 28 Mar 2019 18:35:10 GMT):
we have no enforcement mechanism or policy. I can write that down

swetha (Thu, 28 Mar 2019 18:35:31 GMT):
I prefer that it isn't run with our tests by default

MHBauer (Thu, 28 Mar 2019 18:36:04 GMT):
and I prefer to get lots of information out of things that I run.

swetha (Thu, 28 Mar 2019 18:37:04 GMT):
i don't find value in the cover percentage and thinks it gives the wrong impression. basically i don't think it is accurate information

MHBauer (Thu, 28 Mar 2019 18:37:35 GMT):
to whether or not code is executing?

MHBauer (Thu, 28 Mar 2019 18:37:50 GMT):
I'm not asking for us to target a number, and have no intention to

MHBauer (Thu, 28 Mar 2019 18:38:21 GMT):
when I write a test, I need to know if it's executing the code, the number indicates that.

MHBauer (Thu, 28 Mar 2019 18:38:33 GMT):
(really, the profile)

swetha (Thu, 28 Mar 2019 18:39:32 GMT):
I feel like we are going into the direction of targeting a number by starting to "publish" a number

swetha (Thu, 28 Mar 2019 18:39:47 GMT):
and it feels like "publishing" because this is what is run in our ci

MHBauer (Thu, 28 Mar 2019 18:41:27 GMT):
I can see that argument, but what would make it disregardable

MHBauer (Thu, 28 Mar 2019 18:41:43 GMT):
something in Contributing?

swetha (Thu, 28 Mar 2019 18:42:32 GMT):
not sure that would stop people to going to targeting a number

MHBauer (Thu, 28 Mar 2019 18:42:49 GMT):
I don't know what that means. What does that look like?

MHBauer (Thu, 28 Mar 2019 18:43:21 GMT):
the first issue I see that says "more tests for increased code coverage" I'm closing.

MHBauer (Thu, 28 Mar 2019 18:43:32 GMT):
that's a misuse of the tool

MHBauer (Thu, 28 Mar 2019 18:44:07 GMT):
if the makefile is only for CI

MHBauer (Thu, 28 Mar 2019 18:44:28 GMT):
then I need a morgan.mk to include my personal runners.

MHBauer (Thu, 28 Mar 2019 18:44:41 GMT):
cause I need something in the repo to do development.

MHBauer (Thu, 28 Mar 2019 18:46:36 GMT):
I can start doing conditionals on the environment to detect the build system and remove the flag, but it seems excessive.

MHBauer (Thu, 28 Mar 2019 18:46:47 GMT):
though perhaps we need something like that already.

swetha (Thu, 28 Mar 2019 18:48:03 GMT):
I think that is excessive. Our makfile isn't only for ci, but ci is one of the main uses for it. I will say i don't use the makefile while I develop. I run it once before i push so i run everything that is on ci

MHBauer (Thu, 28 Mar 2019 18:49:23 GMT):
well what do you run? let's add some of that.

swetha (Thu, 28 Mar 2019 18:49:34 GMT):
If others are okay with the cover profile being produced at each run, im okay with it. But if it is up to me I prefer it not there

MHBauer (Thu, 28 Mar 2019 18:49:39 GMT):
I was going to suggest adding a watch, but I figured that't be kicked back.

swetha (Thu, 28 Mar 2019 18:50:16 GMT):
i do a watch on the repo im working on and i do tdd so i know the code i add is getting tested because i start with failing tests

swetha (Thu, 28 Mar 2019 18:50:50 GMT):
thats more of a process than an actual command

MHBauer (Thu, 28 Mar 2019 18:51:19 GMT):
I think we all know I'm not strict tdd.

swetha (Thu, 28 Mar 2019 18:52:00 GMT):
i didn't say its a requirement, just how i develop and why i don't really use the makefile

MHBauer (Thu, 28 Mar 2019 18:52:02 GMT):
and there is no possible mechanism to enforce that.

MHBauer (Thu, 28 Mar 2019 18:52:17 GMT):
that doesn't really explain that.

swetha (Thu, 28 Mar 2019 18:53:14 GMT):
the make file also doesn't focus on packages

MHBauer (Thu, 28 Mar 2019 18:53:17 GMT):
tdd doesn't explain not using the makefile.

swetha (Thu, 28 Mar 2019 18:53:19 GMT):
which i don't think it shouldn't

MHBauer (Thu, 28 Mar 2019 18:53:23 GMT):
to be more explicit

MHBauer (Thu, 28 Mar 2019 18:53:37 GMT):
doesn't focus on packages?

swetha (Thu, 28 Mar 2019 18:53:38 GMT):
just more difficult to run/test things with the makefile

swetha (Thu, 28 Mar 2019 18:53:58 GMT):
i use focuses, ginkgo watch, package specific tests etc

MHBauer (Thu, 28 Mar 2019 18:54:12 GMT):
well is there something we can add to make it more easy/useful

swetha (Thu, 28 Mar 2019 18:54:15 GMT):
doing a make unit-test isn't useful to me when im developing. its something i do at the very end

MHBauer (Thu, 28 Mar 2019 18:54:25 GMT):
and if not, can we document what is easier

swetha (Thu, 28 Mar 2019 18:54:51 GMT):
no, im okay with how i do things. i don't think its the job of the makefile to adapt to my development style

swetha (Thu, 28 Mar 2019 18:55:11 GMT):
also not sure what could be made into a target there which would be easier than just typing out the command

MHBauer (Thu, 28 Mar 2019 18:55:13 GMT):
there aren't exactly a lot of people here.

swetha (Thu, 28 Mar 2019 18:55:39 GMT):
people have been using the makefile to build and run things. just not for development

MHBauer (Thu, 28 Mar 2019 18:55:44 GMT):
I understand that, but how do people know what to type if we don't write it down?

swetha (Thu, 28 Mar 2019 18:56:16 GMT):
that puts the burden of teaching people how to use ginkgo on us

swetha (Thu, 28 Mar 2019 18:56:47 GMT):
in terms of teaching people tdd, everyone has their own style with that

swetha (Thu, 28 Mar 2019 18:57:05 GMT):
i am not using special features of ginkgo

MHBauer (Thu, 28 Mar 2019 18:57:05 GMT):
well, we use ginkgo

MHBauer (Thu, 28 Mar 2019 18:57:10 GMT):
so, yes, we have to do that.

swetha (Thu, 28 Mar 2019 18:57:21 GMT):
no, we show them how to run the integration tests and the unit tests

MHBauer (Thu, 28 Mar 2019 18:57:26 GMT):
how

swetha (Thu, 28 Mar 2019 18:57:27 GMT):
which you can still run using go test

swetha (Thu, 28 Mar 2019 18:58:05 GMT):
the commands are in our repo for running integration and unit tests

MHBauer (Thu, 28 Mar 2019 18:58:07 GMT):
that's a distraction from a more useful flow.

MHBauer (Thu, 28 Mar 2019 18:58:18 GMT):
in the makefile, or where else?

swetha (Thu, 28 Mar 2019 18:58:24 GMT):
in the makefile

MHBauer (Thu, 28 Mar 2019 18:58:40 GMT):
I think we need more of a devguide.

swetha (Thu, 28 Mar 2019 18:59:06 GMT):
i would agree if we had more active developers

MHBauer (Thu, 28 Mar 2019 19:00:17 GMT):
well, I'm thinking I'll put some words into contributing.

MHBauer (Thu, 28 Mar 2019 19:34:33 GMT):
pushed a big update.

MHBauer (Thu, 28 Mar 2019 19:34:49 GMT):
I really couldn't come up with a good reason not to make a new make target.

MHBauer (Thu, 28 Mar 2019 19:41:39 GMT):
we don't have a mechanism, or a way to track it over time right now anyway, so I'm fine with dropping it in CI.

MHBauer (Thu, 28 Mar 2019 19:41:50 GMT):
I think it's an interesting SIGNAL, but should not be a TARGET.

rameshthoomu (Fri, 29 Mar 2019 13:54:34 GMT):
Could you please review this https://gerrit.hyperledger.org/r/#/c/30448/

swetha (Fri, 29 Mar 2019 16:56:27 GMT):
@rameshthoomu taking a look now

swetha (Fri, 29 Mar 2019 17:52:09 GMT):
Looking to add diagrams to the readme, which of the following seems better?

swetha (Fri, 29 Mar 2019 17:52:22 GMT):

EndToEnd.jpg

swetha (Fri, 29 Mar 2019 17:54:59 GMT):

EVMCC-Arch.jpg

swetha (Fri, 29 Mar 2019 17:58:29 GMT):
@lehors @MHBauer @guoger ^^

MHBauer (Fri, 29 Mar 2019 18:10:34 GMT):
not sure the arch thing is useful for readme, maybe in a dev doc location

MHBauer (Fri, 29 Mar 2019 18:11:03 GMT):
e2e image is sweet, but might want to complicate it up, or provide two versions, one that has more complications so people understand how to use it.

swetha (Fri, 29 Mar 2019 18:17:32 GMT):
what would be the complications?

swetha (Fri, 29 Mar 2019 18:18:06 GMT):
The arch diagram shows a little better how evmcc and fab3 fit in the fabric world. we can simplify it a bit

swetha (Fri, 29 Mar 2019 18:18:18 GMT):
don't need to have all the different components labeled

swetha (Fri, 29 Mar 2019 18:19:23 GMT):
but im in between how detailed the diagram should be versus not. the intention is to show how fab3 and evmcc fit in fabric as well as showing that the dapp and smart contract are the pieces that can stay the same from ethereum. with that in mind, im leaning towards the end to end

MHBauer (Fri, 29 Mar 2019 18:21:50 GMT):
e2e for sure,

MHBauer (Fri, 29 Mar 2019 18:22:01 GMT):
I mean, multiple fa3s, one for each user type thing.

MHBauer (Fri, 29 Mar 2019 18:22:11 GMT):
show that the fa3 is not the point, the evmcc is still the point.

MHBauer (Fri, 29 Mar 2019 19:32:13 GMT):
@lehors are you still around? I'm not sure how to say it differently for https://gerrit.hyperledger.org/r/#/c/30505/2/CONTRIBUTING.md@28 I wrote a comment on your comment, but I want to be clear. We had a big discussion yesterday. starts at https://chat.hyperledger.org/channel/fabric-evm?msg=EWxzBmbSYsoTsGtaB

lehors (Fri, 29 Mar 2019 21:23:23 GMT):
@swetha I think for the README a highlevel diagram is all that's needed - I don't think the intended audience would necessarily be familiar with fabric's architecture and really benefit from a lot of details involving some of the internals of fabric such as the state manager vs ledger

lehors (Fri, 29 Mar 2019 21:24:08 GMT):
now, I think there may be a way to improve the first one to be closer to the real thing, which might somewhere in between those two diagrams you have

lehors (Fri, 29 Mar 2019 21:24:08 GMT):
now, I think there may be a way to improve the first one to be closer to the real thing, which might be somewhere in between those two diagrams you have

lehors (Fri, 29 Mar 2019 21:34:01 GMT):
@MHBauer thanks for the pointer to yesterday's discussion but this doesn't tell me WHY @swetha doesn't want to look at test coverage only that she doesn't

lehors (Fri, 29 Mar 2019 21:34:26 GMT):
what am I missing?

swetha (Fri, 29 Mar 2019 21:34:36 GMT):
Hahah, i don't mind looking at it. I just think it should be an local development tool not on ci

lehors (Fri, 29 Mar 2019 21:35:47 GMT):
well, you could say the same thing about formatting and linting then

lehors (Fri, 29 Mar 2019 21:36:29 GMT):
it is useful to have all these things done automatically as part of the CI because it informs us on the status of the code and helps us improve the overall quality

swetha (Fri, 29 Mar 2019 21:36:31 GMT):
Formatting and linting though we are following and enforcing

swetha (Fri, 29 Mar 2019 21:36:38 GMT):
I can't say the same about test coverage

lehors (Fri, 29 Mar 2019 21:36:43 GMT):
exactly

lehors (Fri, 29 Mar 2019 21:36:52 GMT):
why treating coverage differently??

swetha (Fri, 29 Mar 2019 21:37:05 GMT):
And part of the test coverage is on integration tests which we can't get an accurate cover profile of

swetha (Fri, 29 Mar 2019 21:37:17 GMT):
So I feel like the numbers are inaccurate and give the wrong impression

lehors (Fri, 29 Mar 2019 21:37:28 GMT):
ok, that's a better answer :)

MHBauer (Fri, 29 Mar 2019 21:37:47 GMT):
I'm fine with either of you changing the wording.

lehors (Fri, 29 Mar 2019 21:37:54 GMT):
typically coverage would be done on unit tests

MHBauer (Fri, 29 Mar 2019 21:39:11 GMT):
What mechanism does core fabric have? where are the reports?

MHBauer (Fri, 29 Mar 2019 21:39:21 GMT):
I've never seen it, so I want to know and follow if there is.

lehors (Fri, 29 Mar 2019 21:41:00 GMT):
it's in fabric/scripts

lehors (Fri, 29 Mar 2019 21:41:05 GMT):
it's in the Makefile

lehors (Fri, 29 Mar 2019 21:41:43 GMT):
as we can run the unit-tests collecting coverage

lehors (Fri, 29 Mar 2019 21:41:43 GMT):
we can run the unit-tests collecting coverage

lehors (Fri, 29 Mar 2019 21:42:10 GMT):
now, I have to admit not to know the latest on that and I'm not sure we do that systematically anymore

lehors (Fri, 29 Mar 2019 21:42:45 GMT):
we've had to turn off a whole bunch of things because the CI was taking too long to complete

lehors (Fri, 29 Mar 2019 21:43:19 GMT):
so, we now have different levels of testing and the one that gets triggered on every push isn't as thorough as it used to be

lehors (Fri, 29 Mar 2019 21:43:33 GMT):
so I don't think we do coverage at every run

lehors (Fri, 29 Mar 2019 21:44:30 GMT):
but we do have all the mechanics in place and keep an eye on coverage so that we don't go off rail

lehors (Fri, 29 Mar 2019 21:44:59 GMT):
@cbf should be able to tell where we stand nowadays

lehors (Fri, 29 Mar 2019 21:49:08 GMT):
@cbf how/when do we measure test coverage for fabric nowadays? and what's the target set at?

MHBauer (Fri, 29 Mar 2019 23:01:23 GMT):
and do we have benchmarks....

guoger (Sat, 30 Mar 2019 02:07:15 GMT):
i think we have coverage on UT at least in Fabric

klenik (Mon, 01 Apr 2019 14:07:55 GMT):
[Technical question] Can I utilize the `value` and `gas` variables passed to Burrow's EVM in evmcc? `value` would be of interest for me, since I'm trying to test some contracts (recreate vulnerabilities) from the public world that transfer ether. But since this EVM is picked out of its context and put under Fabric, I'm not sure how the initial `value` values/balances are bootstrapped.

cbf (Mon, 01 Apr 2019 15:51:37 GMT):
test coverage metrics are stupid, but if you want a number, I can give you one

cbf (Mon, 01 Apr 2019 15:52:14 GMT):
I set the bar at 85% but again, this is almost meaningless

cbf (Mon, 01 Apr 2019 15:52:35 GMT):
it should be high, but not too high

swetha (Mon, 01 Apr 2019 17:00:16 GMT):
@klenik Neither `value` or `gas` is configurable from the user. There currently is no native underlying token in Fabric so transfering tokens from one account to another is not doable through just the evmcc. If you need tokens, we expect you create your own token contract, and use that for your purposes as ERC20 contracts will work with the evmcc.

swetha (Mon, 01 Apr 2019 17:00:35 GMT):
Only contract accounts are stored on the ledger, and user accounts are generated on the fly

swetha (Mon, 01 Apr 2019 17:00:51 GMT):
We do this because we don't keep any balance associated with a user

klenik (Mon, 01 Apr 2019 17:51:50 GMT):
@swetha Thanks, confirmed my suspicions :thumbsup:

swetha (Mon, 01 Apr 2019 17:54:05 GMT):
@klenik As a related question, would you want gas to be configurable? If so what use case do you see that helping? We made gas hardcoded for the time being but would be open to making it configurable given enough reasoning as to why that would be useful in the Fabric setting

klenik (Mon, 01 Apr 2019 17:58:39 GMT):
Well, Fabric allows setting the execution timeout of transactions. Gas has the same purpose for the EVM. So a hardcoded gas value is effectively a limit for a Fabric transaction targeting evmcc, regardless of the Fabric-level setting. But since EVM codes aren't that "big", I'd be surprised if this would be a real limitation and not just a theoretical one.

swetha (Mon, 01 Apr 2019 18:03:48 GMT):
That was our though process too. But just wanted to get another perspective

klenik (Mon, 01 Apr 2019 18:04:04 GMT):
[This statemanager interface](https://github.com/hyperledger/fabric-chaincode-evm/blob/413ebda94d103ff563786c572a27444d472e0cb8/statemanager/statemanager.go#L19) has a few more corresponding methods defined on Burrow's ReaderWriter (or something like this) interface, right? As I see these are the high level storage/account operations. So if I wanted to hack together a quick-and-dirty balance support, is this the right place to start?

swetha (Mon, 01 Apr 2019 18:08:24 GMT):
You probably don't need to do too much in the statemanager interface because the it blindly saves the accounts that it is given. The account is the burrow account type so it should have the ability to store a balance. You may need to add a cache for accounts depending on you plan on accessing accounts that you have just written to in the same transaction: https://github.com/hyperledger/fabric-chaincode-evm/blob/413ebda94d103ff563786c572a27444d472e0cb8/statemanager/statemanager.go#L31

swetha (Mon, 01 Apr 2019 18:09:55 GMT):
The work has to be done in the [evmc](https://github.com/hyperledger/fabric-chaincode-evm/blob/413ebda94d103ff563786c572a27444d472e0cb8/evmcc/evmcc.go)

swetha (Mon, 01 Apr 2019 18:10:37 GMT):
You would have do edit it so it creates an account for a user it hasn't seen before and give it a starting balance

swetha (Mon, 01 Apr 2019 18:13:37 GMT):
And then you would have to do some arg parsing be able to accept `value` as an arg pass that along to the vm.call invocation

MHBauer (Mon, 01 Apr 2019 18:15:14 GMT):
I think we should link to the wiki in our README

MHBauer (Mon, 01 Apr 2019 18:15:27 GMT):
that way we can put stuff in easire than making a PR

klenik (Mon, 01 Apr 2019 18:22:57 GMT):
@swetha Cool, thanks for the detailed guide! Any thoughts about bootstrapping certain accounts with initial balances? Who will mint the first "coin"? Haven't looked into the design docs of Fabric's token support, but I guess the identity that deploys the evmcc chaincode should have a say in the initial distribution of a certain amount of "coin". Although a Remix-style approach would also be fine for me, e.g., giving a fix initial amount for every newly encountered user

MHBauer (Mon, 01 Apr 2019 18:49:39 GMT):
@klenik no coins, no tokens. We haven't looked into fabric tokens in any detail, but it's the obvious thing to gonnect too.

MHBauer (Mon, 01 Apr 2019 18:52:50 GMT):
@lehors @swetha Should i take out the code coverage paragraph? Everybody seems confused about it.

swetha (Mon, 01 Apr 2019 18:54:49 GMT):
@klenik I would say thats really up to what you are trying to test out and what works out the easiest. One thing to note is the tips I gave above only add balances to users in the evmcc world. None of those balances would transfer to the rest of fabric

MHBauer (Mon, 01 Apr 2019 18:54:56 GMT):
I want to get https://gerrit.hyperledger.org/r/#/c/30505/ merged or fixed so it can be merged. I didn't think it was that controversial.

lehors (Mon, 01 Apr 2019 18:55:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=tbFaPfPRsyzpf4TrQ) @MHBauer I think you could rewrite it to say exactly what you mean. Just don't be cheap on the number of words. :-)

lehors (Mon, 01 Apr 2019 18:56:13 GMT):
seriously, there is just too much compacted in that one or two sentences

MHBauer (Mon, 01 Apr 2019 18:57:09 GMT):
Hmn, okay, I'll try.

swetha (Mon, 01 Apr 2019 18:58:21 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=AQcjYNKhanSnbryu3) I would also say that there is work in Fabric to introduce tokens. We haven't looked into that and what that could mean for the EVM but something you might be interested in

MHBauer (Mon, 01 Apr 2019 19:04:09 GMT):
okay, here we go again. smaller, more direct, sentences.

MHBauer (Mon, 01 Apr 2019 19:04:25 GMT):
It'd be great if we didn't run the builld for docs-only changes.

swetha (Mon, 01 Apr 2019 19:33:42 GMT):
Made comments on the patch

swetha (Mon, 01 Apr 2019 19:34:47 GMT):
@MHBauer also realized I merged the address filter for getLogs prematurely. Since right now the types tests are not being run in ci

MHBauer (Mon, 01 Apr 2019 19:37:44 GMT):
what, why not? didn't I add the suite?

MHBauer (Mon, 01 Apr 2019 19:38:33 GMT):
15:06:34 [1553897158] Types Suite - 19/19 specs ••••••••••••••••••• SUCCESS! 4.383135ms PASS

MHBauer (Mon, 01 Apr 2019 19:38:37 GMT):
looks like it's running

swetha (Mon, 01 Apr 2019 19:40:10 GMT):
oh whoops my bad. oh its the '-r'

swetha (Mon, 01 Apr 2019 19:40:52 GMT):
sorry i thought a change was necessary in the makefile

MHBauer (Mon, 01 Apr 2019 19:44:07 GMT):
yea, that whole thing makes no sense, which is why I'm trying to fix it

MHBauer (Mon, 01 Apr 2019 19:44:14 GMT):
(it make a little sense)

MHBauer (Mon, 01 Apr 2019 19:53:44 GMT):
needs some integration tests, which I'm not looking forward to writing https://gerrit.hyperledger.org/r/#/c/29170/

MHBauer (Mon, 01 Apr 2019 19:53:58 GMT):
change is already yellow sized, groan

MHBauer (Mon, 01 Apr 2019 19:55:04 GMT):
maybe it's time for that refactor.

lehors (Mon, 01 Apr 2019 19:57:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=NZxubQBs8ASXuRATR) @MHBauer Amen to that! Mind you, I said that about 3 years ago and a couple of times a plugin was set to allow you to direct the CI not to run by simply adding "[ci-skip] to the commit message but it caused problems so they had to turn it off. I find that very annoying.

MHBauer (Mon, 01 Apr 2019 19:58:03 GMT):
I'd have to learn how to jenkins I think.

swetha (Mon, 01 Apr 2019 20:05:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=A59rgnRPPhvqYcXAr) @MHBauer you also need to add docs

MHBauer (Mon, 01 Apr 2019 20:25:47 GMT):
docs is easy, link to https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getlogs

MHBauer (Mon, 01 Apr 2019 20:25:52 GMT):
:-D

ZichengWang (Mon, 01 Apr 2019 20:41:36 GMT):
Has joined the channel.

MHBauer (Tue, 02 Apr 2019 19:26:31 GMT):
@swetha good suggestions. pr is back to yellow sized

swetha (Tue, 02 Apr 2019 19:36:33 GMT):
glad i could be of help :)

MHBauer (Tue, 02 Apr 2019 19:44:20 GMT):
I wonder if I can send bluethanks to external people?

MHBauer (Tue, 02 Apr 2019 20:30:09 GMT):
@lehors @swetha let's iterate! https://gerrit.hyperledger.org/r/30505

MHBauer (Tue, 02 Apr 2019 20:30:41 GMT):
@swetha https://gerrit.hyperledger.org/r/#/c/29170/ should be pretty complete now.

MHBauer (Tue, 02 Apr 2019 20:31:26 GMT):
this process makes me wonder about things, but not too closely...

swetha (Tue, 02 Apr 2019 21:29:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=Jm2rfoECFLpeS7iER) @MHBauer I don't see a new patch, but replied to the comments

MHBauer (Tue, 02 Apr 2019 21:52:32 GMT):
oh, did I forget?

MHBauer (Tue, 02 Apr 2019 21:52:40 GMT):
arg

MHBauer (Tue, 02 Apr 2019 21:53:10 GMT):
:-(

MHBauer (Tue, 02 Apr 2019 21:55:52 GMT):
okay, silly thing looks up to me now

guoger (Wed, 03 Apr 2019 09:07:45 GMT):
i see Morgan in https://gerrit.hyperledger.org/r/c/30566/, and probably we could jus reference it in our contribution guideline

MHBauer (Wed, 03 Apr 2019 18:16:37 GMT):
I can turn it into a blog, but I didn't like the "very good coverage",

MHBauer (Wed, 03 Apr 2019 18:16:39 GMT):
meaningless

MHBauer (Wed, 03 Apr 2019 18:17:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=w6ioy2ad3RiR43xWj) @lehors commit message isn't a great place for that, but interesting concept. need to learn jenkins, I guess.

cbf (Wed, 03 Apr 2019 18:57:47 GMT):
we don't do a full build for doc-only changes

MHBauer (Wed, 03 Apr 2019 18:59:55 GMT):
How is that done? jenkins config or makefile git magic?

MHBauer (Wed, 03 Apr 2019 20:21:18 GMT):
more tests, back to orange sized.

swetha (Wed, 03 Apr 2019 20:56:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=foHQBzGcYpA9cueKg) @MHBauer I am curious how this is done too

cbf (Wed, 03 Apr 2019 21:26:44 GMT):
I believe that you need to tag the commit message as docs or something - ask Ramesh

guoger (Thu, 04 Apr 2019 03:28:36 GMT):
https://gerrit.hyperledger.org/r/c/29170/#message-aa7bf5e6_2f5fd913

MHBauer (Thu, 04 Apr 2019 03:29:34 GMT):
"It would be helpful for readers to include the example from design doc as code comment." swetha's example? or which?

MHBauer (Thu, 04 Apr 2019 03:30:34 GMT):
I agree generally, I wasn't sure what would be too much, or hold it up.

MHBauer (Thu, 04 Apr 2019 03:30:54 GMT):
I can add mucho docs tomorrow/thursday & friday, as I document everything else.

guoger (Thu, 04 Apr 2019 03:36:09 GMT):
basically the topic matching rules, i.e. ``` [] "anything" [A] "A in first position (and anything after)" [null, B] "anything in first position AND B in second position (and anything after)" [A, B] "A in first position AND B in second position (and anything after)" [[A, B], [A, B]] "(A OR B) in first position AND (A OR B) in second position (and anything after)" ``` i need to go back to that design doc several times to refresh my memory while reading code

MHBauer (Thu, 04 Apr 2019 14:49:36 GMT):
to me that's not a fully complete description of things.

MHBauer (Thu, 04 Apr 2019 14:49:47 GMT):
but sure.

MHBauer (Thu, 04 Apr 2019 15:59:42 GMT):
@swetha where is the documentation for each function?

MHBauer (Thu, 04 Apr 2019 16:01:20 GMT):
ah, fa3 instructions

MHBauer (Thu, 04 Apr 2019 16:01:29 GMT):
those in any order?

MHBauer (Thu, 04 Apr 2019 16:01:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=xyPkCoEJKqPof9Gxs) @MHBauer no i don't think i put them in a specific order. maybe the order they are in the file?

MHBauer (Thu, 04 Apr 2019 18:01:42 GMT):
can we move fab3_instructions.md to the fab3 folder.

MHBauer (Thu, 04 Apr 2019 18:01:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=Gi7oXi87hw9TQRmFW) @MHBauer mmmm, i think as we collect more docs it would be better to have a docs directory but for right now i think top level just makes it more visible when people first look at the repo

MHBauer (Thu, 04 Apr 2019 18:02:44 GMT):
and is there a reason eventmanager and statemanager aren't in evmcc?

swetha (Thu, 04 Apr 2019 18:39:38 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=GwDXb2jMrcS4GJN7F) @MHBauer We had a discussion about that at the beginning of the project. We settled on we don't want to have a nested repo and want most of it at the top level

swetha (Thu, 04 Apr 2019 18:42:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=8fNXK4y2hM5R8zSZn) @guoger @MHBauer and I went back and forth on understanding the topic matching rules. we need to add a little more to about adding null on the later indices to the effect of `if i explicitly put null in an index it means i don’t care about the value but i do care that it exists`

swetha (Thu, 04 Apr 2019 18:42:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=8fNXK4y2hM5R8zSZn) @guoger @MHBauer and I went back and forth on understanding the topic matching rules. we need to add a little more about adding null on the later indices to the effect of `if i explicitly put null in an index it means i don’t care about the value but i do care that it exists`

swetha (Thu, 04 Apr 2019 18:51:45 GMT):

Screen Shot 2019-04-04 at 9.47.52 AM.png

swetha (Thu, 04 Apr 2019 18:52:21 GMT):
@lehors does that seem like a middle ground from the original images?

lehors (Thu, 04 Apr 2019 19:05:24 GMT):
@swetha yes, that's pretty nice!

swetha (Thu, 04 Apr 2019 19:09:50 GMT):
Yay, I will add that to the README

MHBauer (Thu, 04 Apr 2019 19:16:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=cxpsYmwXXoH9do5LA) @swetha looks messy

swetha (Thu, 04 Apr 2019 19:19:44 GMT):
i voiced the same opinion when the decision was made

swetha (Thu, 04 Apr 2019 19:20:28 GMT):
but the counter argument is that this isn't a large project so having everything top level and not hidden was a better approach

MHBauer (Thu, 04 Apr 2019 20:35:58 GMT):
I disagree, it implies that somehow, other things might rely on them, but it's specific to the evmcc

MHBauer (Thu, 04 Apr 2019 20:37:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=44ggeprbZD2o9RJZE) @swetha can you make it bigger when you render it? or make it an SVG?

swetha (Thu, 04 Apr 2019 20:43:43 GMT):
the one here is just a screenshot

swetha (Thu, 04 Apr 2019 20:43:55 GMT):
the image i created should be bigger

MHBauer (Thu, 04 Apr 2019 20:49:54 GMT):
VEKTOR GRAFIX

MHBauer (Thu, 04 Apr 2019 23:40:29 GMT):
bizarre rebase error. should be fixed now. https://gerrit.hyperledger.org/r/#/c/30752/4

MHBauer (Thu, 04 Apr 2019 23:40:29 GMT):
bizarre rebase error. should be fixed now. https://gerrit.hyperledger.org/r/#/c/30752

MHBauer (Thu, 04 Apr 2019 23:45:06 GMT):
``` ```

MHBauer (Thu, 04 Apr 2019 23:45:14 GMT):
``` 16:41:00 • SUCCESS! 58.412517386s PASS 16:41:40 [1554421188] Fab3 - 13/13 specs ••••••••••••• SUCCESS! 48.129590624s PASS 16:41:41 16:41:41 Ginkgo ran 2 suites in 1m53.059008053s 16:41:41 Test Suite Passed [Pipeline] } [Pipeline] // dir [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // timestamps [Pipeline] } [Pipeline] // node [Pipeline] } [Pipeline] // timeout [Pipeline] End of Pipeline Finished: ABORTED ```

MHBauer (Thu, 04 Apr 2019 23:45:16 GMT):
wut

MHBauer (Thu, 04 Apr 2019 23:45:26 GMT):
oh, wrong

swetha (Fri, 05 Apr 2019 17:18:17 GMT):
Pipeline?

MHBauer (Fri, 05 Apr 2019 17:52:54 GMT):
wrong build. not sure how I was looking at it.

MHBauer (Fri, 05 Apr 2019 19:12:15 GMT):
https://gerrit.hyperledger.org/r/#/c/30755/ should be good and tested.

MHBauer (Fri, 05 Apr 2019 19:12:25 GMT):
untis and integrations.

MHBauer (Fri, 05 Apr 2019 19:12:56 GMT):
it's tending towards orange, but it isn't a lot of implementation, mainly use of a new ledger query requires mock.

MHBauer (Fri, 05 Apr 2019 21:21:11 GMT):
for

MHBauer (Fri, 05 Apr 2019 21:21:42 GMT):
@swetha https://gerrit.hyperledger.org/r/#/c/30752/6/Fab3_Instructions.md@305 how about adding " All visible events will be matched against, which will include other instances of the EVM chaincode operating with different chaincode IDs."

MHBauer (Fri, 05 Apr 2019 21:22:12 GMT):
but up above, at 296, after the "these log objects ... on the transaction"

swetha (Fri, 05 Apr 2019 21:22:59 GMT):
yea that sounds good

MHBauer (Fri, 05 Apr 2019 21:36:20 GMT):
should be out now.

tcurdt (Sat, 06 Apr 2019 14:51:34 GMT):
Has joined the channel.

tcurdt (Sat, 06 Apr 2019 15:36:33 GMT):
let's say I use the azure hyperledger farbric deployment - is there an easy way to add the evm? (so one can use web3+solidity)

swetha (Sun, 07 Apr 2019 06:14:28 GMT):
@tcurdt I am not familiar with the azure service. But you should be able to install the evm as you would any chaincode

guoger (Sun, 07 Apr 2019 12:04:32 GMT):
not sure is it's something with my env but when i run [this integration test](https://gerrit.hyperledger.org/r/c/30755/5/integration/fab3/fab3_test.go#346) i got following error: ``` [e][Org1.peer0] 2019-04-07 20:01:34.780 CST [endorser] SimulateProposal -> ERRO 06b [testchannel][b46e07d5] failed to invoke chaincode name:"qscc" , error: transaction returned with failure: proto: field "protos.Response.Message" contains invalid UTF-8 [e][Org1.peer0] github.com/hyperledger/fabric/core/chaincode.processChaincodeExecutionResult [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:265 [e][Org1.peer0] github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239 [e][Org1.peer0] github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/core/endorser/support.go:147 [e][Org1.peer0] github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/core/endorser/endorser.go:142 [e][Org1.peer0] github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/core/endorser/endorser.go:237 [e][Org1.peer0] github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/core/endorser/endorser.go:456 [e][Org1.peer0] github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61 [e][Org1.peer0] github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:32 [e][Org1.peer0] github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler.func1 [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:169 [e][Org1.peer0] github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1 [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:31 [e][Org1.peer0] github.com/hyperledger/fabric/common/grpclogging.UnaryServerInterceptor.func1 [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/common/grpclogging/server.go:91 [e][Org1.peer0] github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1 [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:34 [e][Org1.peer0] github.com/hyperledger/fabric/common/grpcmetrics.UnaryServerInterceptor.func1 [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/common/grpcmetrics/interceptor.go:30 [e][Org1.peer0] github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1 [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:39 [e][Org1.peer0] github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:171 [e][Org1.peer0] github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:982 [e][Org1.peer0] github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1208 [e][Org1.peer0] github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1 [e][Org1.peer0] /Users/guoger/workspace/go-project/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:686 [e][Org1.peer0] runtime.goexit [e][Org1.peer0] /usr/local/go/src/runtime/asm_amd64.s:1337 ``` (although the whole test actually passes...)

guoger (Sun, 07 Apr 2019 12:04:42 GMT):
@MHBauer ^^^^

MHBauer (Mon, 08 Apr 2019 04:48:03 GMT):
that's a peer blowing up

MHBauer (Mon, 08 Apr 2019 04:48:14 GMT):
I haven't seen that

MHBauer (Mon, 08 Apr 2019 04:48:21 GMT):
and I'm not even sure where to start troubleshooting.

MHBauer (Mon, 08 Apr 2019 04:48:38 GMT):
but if you're running it with 'go test' I'd say something in 1.4.1 or 2.0 is blowing up

MHBauer (Mon, 08 Apr 2019 04:48:56 GMT):
and if you've got 1.4.0 checked out, I've not an idea where to start.

MHBauer (Mon, 08 Apr 2019 04:57:37 GMT):
I'll start it running with ginkgo and let it go, but if it doesn't FAIL, then I can chalk down that fabric is pretty resilient.

MHBauer (Mon, 08 Apr 2019 04:57:50 GMT):
cause we certainly aren't retrying during the test.

MHBauer (Mon, 08 Apr 2019 04:58:46 GMT):
overall I think it's ready if we can squeeze it in.

Shezay (Mon, 08 Apr 2019 13:55:49 GMT):
Has joined the channel.

Shezay (Mon, 08 Apr 2019 13:57:17 GMT):
Hi, I have a question about Fab3, if I set the user parameter of a Fab3 instance and then connect using web3, is there anything that prevents some other person from connecting with web3 to my proxy with my user?

MHBauer (Mon, 08 Apr 2019 15:21:05 GMT):
there's no encryption or anything, but the fact that it's running locally for you makes it inaccessible.

swetha (Mon, 08 Apr 2019 19:44:47 GMT):
@guoger ran into the same problem doing some manual testing: ``` curl http://127.0.0.1:5000 -X POST -H "Content-Type:application/json" -d '{ "jsonrpc":"2.0", "method": "eth_getLogs", "id":1, "params":[{"blockHash":"0xa21538254a4d6dc0115619151029d24833655b401d85bbe06d6c3ba791ca1345"}] }' | jq . % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 499 100 344 100 155 306 138 0:00:01 0:00:01 --:--:-- 306 { "jsonrpc": "2.0", "error": { "code": -32000, "message": "failed to find block by block hash: QueryBlockByHash failed: Transaction processing for endorser [169.63.236.150:30110]: Chaincode status Code: (500) UNKNOWN. Description: transaction returned with failure: proto: field \"protos.Response.Message\" contains invalid UTF-8", "data": null }, "id": 1 } ```

MHBauer (Mon, 08 Apr 2019 19:46:53 GMT):
huh

swetha (Mon, 08 Apr 2019 19:47:36 GMT):
im investigating futher

MHBauer (Mon, 08 Apr 2019 19:47:37 GMT):
how do the fab3 logs look?

swetha (Mon, 08 Apr 2019 19:47:42 GMT):
fab3 logs have nothign

swetha (Mon, 08 Apr 2019 19:47:42 GMT):
fab3 logs have nothing

swetha (Mon, 08 Apr 2019 19:47:47 GMT):
ill turn on debug in a second

MHBauer (Mon, 08 Apr 2019 19:47:49 GMT):
did you turn debug on?

MHBauer (Mon, 08 Apr 2019 19:47:50 GMT):
okay

MHBauer (Mon, 08 Apr 2019 19:48:08 GMT):
(we should make a jira fo rthat, or switch to flogging)

swetha (Mon, 08 Apr 2019 19:48:23 GMT):
also capitalized 'H' in blockHash but don't think that is the problem

MHBauer (Mon, 08 Apr 2019 19:48:31 GMT):
?

MHBauer (Mon, 08 Apr 2019 19:48:40 GMT):
it's capitalized more than it's not in the example.

MHBauer (Mon, 08 Apr 2019 19:48:47 GMT):
so, I went with it.

swetha (Mon, 08 Apr 2019 19:50:31 GMT):
i think spec doesn't have it capitalized but looks like go took care of that?

MHBauer (Mon, 08 Apr 2019 19:51:03 GMT):
spec has btoh

MHBauer (Mon, 08 Apr 2019 19:51:07 GMT):
``` blockhash: DATA, 32 Bytes - (optional) With the addition of EIP-234 (Geth >= v1.8.13 or Parity >= v2.1.0), blockHash is a new filter option which restricts the logs returned to the single block with the 32-byte hash blockHash. Using blockHash is equivalent to fromBlock = toBlock = the block number with hash blockHash. If blockHash is present in the filter criteria, then neither fromBlock nor toBlock are allowed. ```

MHBauer (Mon, 08 Apr 2019 19:51:11 GMT):
but more blockHash

MHBauer (Mon, 08 Apr 2019 19:51:14 GMT):
than blockhash

swetha (Mon, 08 Apr 2019 19:52:59 GMT):
debug logs don't have anything unfortunately: ``` looking for block by hash {"method": "GetLogs"} 2019-04-08T12:52:19.863-0700 DEBUG fab3.ethservice fab3/ethservice.go:230 Received a request for GetBlockByNumber 2019-04-08T12:52:19.863-0700 DEBUG fab3.ethservice fab3/ethservice.go:232 Params are : [latest false] 2019-04-08T12:52:20.224-0700 DEBUG fab3.ethservice fab3/ethservice.go:285 block has transaction hash:18ec90417c244d6ffdb1273ae2635440ff02d71e949cb3ce0bb71c21ead5d5f5 2019-04-08T12:52:20.224-0700 DEBUG fab3.ethservice fab3/ethservice.go:313 asked for blocklatestfound block{0x16 0xa21538254a4d6dc0115619151029d24833655b401d85bbe06d6c3ba791ca1345 0xcb864f24525655384466020957c79f60d341f77da29b756fa2d7ff36b51b0133 [0x18ec90417c244d6ffdb1273ae2635440ff02d71e949cb3ce0bb71c21ead5d5f5]} ```

swetha (Mon, 08 Apr 2019 19:55:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=EsB2vfc4C4tCizteS) @MHBauer yea but the name of the field says blockhash. and looks like the new docs also use blockhash. either way that isn't the thing causing the error: https://github.com/ethereum/EIPs/blob/4e169dcb6e1d237c9f2e75eb347efb3c94b54f74/EIPS/eip-1474.md

MHBauer (Mon, 08 Apr 2019 20:07:00 GMT):
I guess, "what does geth say"

MHBauer (Mon, 08 Apr 2019 20:08:19 GMT):
maddeningly inconsistent.

swetha (Mon, 08 Apr 2019 20:13:56 GMT):
geth accepts both

swetha (Mon, 08 Apr 2019 20:14:02 GMT):
but returns blockHash

swetha (Mon, 08 Apr 2019 20:14:17 GMT):
it doesn't really matter, because go seems to be handling this for us?

swetha (Mon, 08 Apr 2019 20:20:36 GMT):
The problem has to do with how we decode the hash and send it to the ledger. looking into what format it needs to be in

MHBauer (Mon, 08 Apr 2019 20:22:24 GMT):
how the heck is the test not failing?

MHBauer (Mon, 08 Apr 2019 20:23:57 GMT):
oh shoot, I made the proto mistake, I think.

MHBauer (Mon, 08 Apr 2019 20:30:23 GMT):
looks like it.

MHBauer (Mon, 08 Apr 2019 22:52:26 GMT):
should probably flag up pprof so we can attach the debugger if necessary

MHBauer (Tue, 09 Apr 2019 01:10:47 GMT):
@guoger good catch

MHBauer (Tue, 09 Apr 2019 01:10:51 GMT):
some furious coding later

MHBauer (Tue, 09 Apr 2019 01:11:00 GMT):
we fixed the huge bug

MHBauer (Tue, 09 Apr 2019 01:11:01 GMT):
https://gerrit.hyperledger.org/r/#/c/30755/

guoger (Tue, 09 Apr 2019 02:18:50 GMT):
> I don't think contracts are a part of the definition of dapp. I thought dapp was to an app and smart contract was sort of the backend. The goal here is to use terminology that ethereum users are familiar with and that they would understand they can bring these pieces pretty much unaltered. If not dapp what would be the right word? I think Frontend is probably the closest. DApp in ethereum would include smart contracts

swetha (Tue, 09 Apr 2019 02:25:37 GMT):
would web3 app work?

swetha (Tue, 09 Apr 2019 02:27:10 GMT):

EndToEnd.png

swetha (Tue, 09 Apr 2019 02:27:15 GMT):
@guoger ^^

guoger (Tue, 09 Apr 2019 02:27:47 GMT):
ah, that's actually better :)

swetha (Tue, 09 Apr 2019 02:30:21 GMT):
i like that, and i will push that up

MHBauer (Tue, 09 Apr 2019 02:38:38 GMT):
I'm fine with this

MHBauer (Tue, 09 Apr 2019 02:39:07 GMT):
@guoger the -1 is to see if you guys can +2 over it. I've never seen that

guoger (Tue, 09 Apr 2019 02:39:48 GMT):
:joy:

MHBauer (Wed, 10 Apr 2019 14:13:37 GMT):
looks like we have a release! https://github.com/hyperledger/fabric-chaincode-evm/releases/tag/v0.2.0

MHBauer (Wed, 10 Apr 2019 14:47:23 GMT):
If/when we send out an email I'd like to get people to drop suggestions for the next release in this wiki page, or a doc or something: https://wiki.hyperledger.org/display/fabric/2019-07+July+Release+Planning?src=contextnavpagetreemode

MHBauer (Wed, 10 Apr 2019 20:49:58 GMT):
should we schedule a retro?

MHBauer (Wed, 10 Apr 2019 20:50:06 GMT):
Should we schedule a release planning meeting coming up?

MHBauer (Thu, 11 Apr 2019 18:47:45 GMT):
lookign at jiras

MHBauer (Thu, 11 Apr 2019 18:47:54 GMT):
https://jira.hyperledger.org/browse/FAB-15116 is actually more interesting.

MHBauer (Thu, 11 Apr 2019 18:48:06 GMT):
cause go 1.10 can't generate mocks with the counterfeiter we have

MHBauer (Thu, 11 Apr 2019 18:48:18 GMT):
so, we should switch to some version of 1.11

MHBauer (Thu, 11 Apr 2019 18:49:11 GMT):
also 1.10 is technically unsupported now.

MHBauer (Thu, 11 Apr 2019 18:57:37 GMT):
well, https://gerrit.hyperledger.org/r/30906 for it, we can discuss there.

MHBauer (Thu, 11 Apr 2019 20:42:24 GMT):
@swetha do you like/not-like/care-about the 'enable and use bold in the jenkins build-output' changes?

swetha (Thu, 11 Apr 2019 20:43:06 GMT):
I am indifferent. I am okay either way

swetha (Thu, 11 Apr 2019 20:43:14 GMT):
@MHBauer ^

MHBauer (Thu, 11 Apr 2019 20:59:08 GMT):
thinking I'll edit the PR myself, rebase it, etc.

MHBauer (Thu, 11 Apr 2019 22:46:26 GMT):
@swetha https://gerrit.hyperledger.org/r/#/c/30448/ check it

Akatsuki (Fri, 12 Apr 2019 03:26:33 GMT):
Has joined the channel.

guoger (Fri, 12 Apr 2019 03:50:20 GMT):
@MHBauer why are we upgrading go-sdk dep?

MHBauer (Fri, 12 Apr 2019 14:52:59 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=SF5SaGjkefQ5mzcmZ) @guoger seemed like something we've been talking about doing for a while and I wanted to get that out of the way.

guoger (Fri, 12 Apr 2019 16:03:58 GMT):
ok, i was just wondering whether there's a specific change in new version that we want to pull in. In this case, wouldn't it be better to upgrade once sdk 1.0 is official?

MHBauer (Fri, 12 Apr 2019 16:53:45 GMT):
I don't have any confidence in their 1.0 meaning anything.

MHBauer (Fri, 12 Apr 2019 16:54:11 GMT):
it will be module based, which I don't know if is good or bad for us.

swetha (Fri, 12 Apr 2019 18:37:44 GMT):
i thought we wanted the new block hash code

MHBauer (Fri, 12 Apr 2019 19:04:49 GMT):
they don't have that,

MHBauer (Fri, 12 Apr 2019 19:05:06 GMT):
there's a lot of missing stuff in the fabric files they've copied.

MHBauer (Fri, 12 Apr 2019 19:12:01 GMT):
and the types are still different, so we still can't use upstream

swetha (Fri, 12 Apr 2019 21:13:22 GMT):
oh in that case do we really gain anything from the upgrade?

MHBauer (Fri, 12 Apr 2019 22:33:44 GMT):
I'm not sure. We'd be at the most advanced version before switching to modules. It may be easier to upgrade in the future, but I'm not sure.

MHBauer (Fri, 12 Apr 2019 22:33:44 GMT):
What impact are we having with the current configuration?

mallikarjunasai995 (Sat, 13 Apr 2019 11:38:01 GMT):
Has joined the channel.

swetha (Mon, 15 Apr 2019 19:52:35 GMT):
@MHBauer , @rameshthoomu wants to switch back the third party images to use the actual images and has suggestions to keep the build time short still: " This is what we follow on every new fabric-baseimage release 1) When a new fabric baseimage is out.. say 0.4.16 2) Some repos are required fabric baseimages and thirdparty images.. we update this line and submit patch to ci-managment repo to cache the images https://github.com/hyperledger/ci-management/blob/master/packer/provision/docker.sh#L131 3) It depends on dependent repository owner to update the configuration files (Makefile or ci.properties files) to download latest released version.. If you want to automate this.. We can do this way in Makefile curl -L https://raw.githubusercontent.com/hyperledger/fabric/master/Makefile > Makefile && BASEIMAGE_RELEASE=$(cat Makefile | grep "BASEIMAGE_RELEASE =" | awk '{print $3}') and one more https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Makefile#L86 we don't have amd64-latest tag in hyperledger dockerhub. you can use "latest" or specific release version from here https://hub.docker.com/r/hyperledger/fabric-javaenv/tags "

MHBauer (Mon, 15 Apr 2019 19:54:51 GMT):
I don't want to manually deal with any of this, since we don't actually use the images.

MHBauer (Mon, 15 Apr 2019 19:55:09 GMT):
What impact are we having with the current configuration?

MHBauer (Mon, 15 Apr 2019 19:55:39 GMT):
I didn't configure the existing pipeline to use latest

MHBauer (Mon, 15 Apr 2019 19:55:44 GMT):
and nobody should use latest.

rameshthoomu (Mon, 15 Apr 2019 19:55:56 GMT):
@MHBauer we can automate this as suggested above..

MHBauer (Mon, 15 Apr 2019 19:56:08 GMT):
I'm not responsible for the existing naming scheme either.

MHBauer (Mon, 15 Apr 2019 19:57:35 GMT):
automate it in some commonly available place for everyone to use.

rameshthoomu (Mon, 15 Apr 2019 19:57:56 GMT):
yes..

MHBauer (Mon, 15 Apr 2019 19:58:16 GMT):
because I don't want to maintain it, and have it break when upstream changes some thing.

rameshthoomu (Mon, 15 Apr 2019 19:59:05 GMT):
ok that makes sense... Let me push change to fix these issues..

rameshthoomu (Mon, 15 Apr 2019 19:59:23 GMT):
will let you know the update..

swetha (Mon, 15 Apr 2019 19:59:42 GMT):
Thanks

swetha (Mon, 15 Apr 2019 22:43:22 GMT):
We are going to be having a release planning meeting for the fabric-evm. Thursday 8:00AM PDT Meeting Link: https://ibm.webex.com/ibm/j.php?MTID=mf71b4c786845929feaea96f26e563765

swetha (Mon, 15 Apr 2019 22:43:22 GMT):
We are going to be having a release planning meeting for the fabric-evm. Thursday 8:00AM PDT

swetha (Mon, 15 Apr 2019 22:44:13 GMT):
I am working on getting that and more details such as dial in numbers into the community calendar. Will update with calendar event as soon as I get it.

swetha (Mon, 15 Apr 2019 22:45:04 GMT):
@MHBauer @guoger @lehors @cbf ^^

MHBauer (Mon, 15 Apr 2019 23:07:48 GMT):
@klenik ^

MattWilson8 (Tue, 16 Apr 2019 15:06:33 GMT):
Has joined the channel.

MattWilson8 (Tue, 16 Apr 2019 15:18:37 GMT):
Hi guys I'm new and I was having an issue with the very first step of mounting the EVM, I can't seem to update the docker-compose-cli.yaml file with the volumes in the fabric-evm-chaincode

MattWilson8 (Tue, 16 Apr 2019 15:18:54 GMT):

Screen Shot 2019-04-16 at 16.18.15.png

MHBauer (Tue, 16 Apr 2019 15:23:35 GMT):
@MattWilson8 why not? What error?

MHBauer (Tue, 16 Apr 2019 15:23:42 GMT):
it's a file.

MHBauer (Tue, 16 Apr 2019 15:23:46 GMT):
https://github.com/hyperledger/fabric-samples/blob/release-1.4/first-network/docker-compose-cli.yaml#L80-L85

MHBauer (Tue, 16 Apr 2019 15:24:40 GMT):
my diff looks like

MHBauer (Tue, 16 Apr 2019 15:24:51 GMT):
``` diff --git a/first-network/docker-compose-cli.yaml b/first-network/docker-compose-cli.yaml index a18bbc2..e295d0d 100644 --- a/first-network/docker-compose-cli.yaml +++ b/first-network/docker-compose-cli.yaml @@ -80,6 +80,7 @@ services: volumes: - /var/run/:/host/var/run/ - ./../chaincode/:/opt/gopath/src/github.com/chaincode + - ./../../fabric-chaincode-evm/:/opt/gopath/src/github.com/hyperledger/fabric-chaincode-evm/ - ./crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ - ./scripts:/opt/gopath/src/github.com/hyperledger/fabric/peer/scripts/ - ./channel-artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts ```

MattWilson8 (Tue, 16 Apr 2019 15:38:54 GMT):
Well for one I'm not entirely sure which repo/directory I'm meant to copy the command into, I'll send a screenshot of what happens when I try to

MattWilson8 (Tue, 16 Apr 2019 15:39:49 GMT):

Screen Shot 2019-04-16 at 16.40.24.png

MattWilson8 (Tue, 16 Apr 2019 15:40:35 GMT):
Sorry if I'm being oblivious, any help would be appreciated

MHBauer (Tue, 16 Apr 2019 15:42:32 GMT):
okay, what are you reading?

MHBauer (Tue, 16 Apr 2019 15:42:35 GMT):
where is it?

MattWilson8 (Tue, 16 Apr 2019 15:42:44 GMT):
https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md#build-and-start-the-evm

MHBauer (Tue, 16 Apr 2019 15:43:04 GMT):
it looks like you have the file, and you're in the right directory from that screenshot

MattWilson8 (Tue, 16 Apr 2019 15:43:09 GMT):
Following this video as well https://www.youtube.com/watch?v=VbdJVu8bTaw

MHBauer (Tue, 16 Apr 2019 15:43:33 GMT):
so, now edit the file

MattWilson8 (Tue, 16 Apr 2019 15:44:36 GMT):
Ahh now I get it

MattWilson8 (Tue, 16 Apr 2019 15:44:54 GMT):
Thank you

MHBauer (Tue, 16 Apr 2019 15:46:04 GMT):
a really quick skim of that, doesn't look like it's done in the video, b

MattWilson8 (Tue, 16 Apr 2019 15:46:48 GMT):
Yea he just jump cuts and leaves that bit out

MHBauer (Tue, 16 Apr 2019 15:51:46 GMT):
I'm sure there's other recordings, but not sure any of them have that in it

MHBauer (Tue, 16 Apr 2019 15:52:05 GMT):
maybe some time we can make one

MattWilson8 (Tue, 16 Apr 2019 16:09:32 GMT):
Hi again, I tried to instantiate the chaincode on my channel and got this error

MattWilson8 (Tue, 16 Apr 2019 16:09:44 GMT):

Screen Shot 2019-04-16 at 17.08.44.png

MattWilson8 (Tue, 16 Apr 2019 16:10:20 GMT):
This is from the same tutorial page as previously mentioned

MHBauer (Tue, 16 Apr 2019 16:12:51 GMT):
what are you running on?

MHBauer (Tue, 16 Apr 2019 16:14:07 GMT):
that's an avx instruction.

MattWilson8 (Tue, 16 Apr 2019 16:14:14 GMT):
Mac terminal

MHBauer (Tue, 16 Apr 2019 16:15:31 GMT):
well, unless you're using a computer from 2006, I can't see why that would happen.

MHBauer (Tue, 16 Apr 2019 16:16:05 GMT):
If you could paste the three lines of errors it would help me paste it into google and see what's up

MattWilson8 (Tue, 16 Apr 2019 16:16:42 GMT):
Error: Error endorsing chaincode: rpc error: code = Unknown desc = error starting container: Failed to generate platform-specific docker build: Error returned from build: 2 "# github.com/hyperledger/fabric-chaincode-evm/vendor/github.com/tmthrgd/go-hex chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/vendor/github.com/tmthrgd/go-hex/hex_decode_amd64.s:66: unrecognized instruction "VPCMPGTB" chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/vendor/github.com/tmthrgd/go-hex/hex_decode_amd64.s:68: unrecognized instruction "VPCMPGTB" asm: assembly of chaincode/input/src/github.com/hyperledger/fabric-chaincode-evm/vendor/github.com/tmthrgd/go-hex/hex_decode_amd64.s failed"

MHBauer (Tue, 16 Apr 2019 16:20:31 GMT):
nope, I got nothing. some hits for other instructions, but it's possible in our dependencies somewhere it's broken

swetha (Tue, 16 Apr 2019 16:20:46 GMT):
It looks like your version of the fabric-chaincode-evm isnt compiling

MHBauer (Tue, 16 Apr 2019 16:21:35 GMT):
https://github.com/hyperledger/burrow/issues/905 is the closest thing I could find, and again, only triggered by running on an old computer.

MHBauer (Tue, 16 Apr 2019 16:21:49 GMT):
risky question, but how old is this mac?

MattWilson8 (Tue, 16 Apr 2019 16:22:10 GMT):
2015 version

MattWilson8 (Tue, 16 Apr 2019 16:22:40 GMT):
Macbook Pro

MHBauer (Tue, 16 Apr 2019 16:23:13 GMT):
ya, should be fine, that's @swetha 's machine.

MattWilson8 (Tue, 16 Apr 2019 16:26:07 GMT):
I'm basically trying to run EVM smart contracts in hyperledger fabric for the purpose of benchmarking them, using the Caliper tool. I tired using the IBM cloud tutorial where you create a cluster but in that example the kubernetes version doesn't support docker anymore so you can't instantiate the chaincode

MattWilson8 (Tue, 16 Apr 2019 16:26:34 GMT):
I don't know if any of you are familiar with that example

swetha (Tue, 16 Apr 2019 16:27:15 GMT):
Have you altered the fabric chaincode evm code?

MattWilson8 (Tue, 16 Apr 2019 16:28:18 GMT):
No I haven't altered any code

swetha (Tue, 16 Apr 2019 16:28:20 GMT):
And whi he repo are you using for the cloud tutorial? I maintain one of them. We have a solution to docker but requires a 2 step process

MattWilson8 (Tue, 16 Apr 2019 16:30:05 GMT):
https://github.com/swetharepakula/fabric-evm-ibm-container-service/

MattWilson8 (Tue, 16 Apr 2019 16:30:28 GMT):
That one, which i assume is yours?

swetha (Tue, 16 Apr 2019 16:30:41 GMT):
Yes, that is mine

swetha (Tue, 16 Apr 2019 16:30:53 GMT):
There is a branch there that is `dind`

swetha (Tue, 16 Apr 2019 16:31:10 GMT):
that is meant to solve the problem that iks no longer uses docker

swetha (Tue, 16 Apr 2019 16:31:39 GMT):
but instantiating will still fail after about 20-30 min and then you have to re run the instantiation for the network to work

swetha (Tue, 16 Apr 2019 16:31:56 GMT):
I haven't figured out how to improve that

swetha (Tue, 16 Apr 2019 16:32:06 GMT):
But lets try to solve your current issue

MattWilson8 (Tue, 16 Apr 2019 16:32:32 GMT):
Right ok

swetha (Tue, 16 Apr 2019 16:32:55 GMT):
Just so I understand what you are doing, you are using a modified version of this file: https://github.com/hyperledger/fabric-samples/blob/release-1.4/first-network/docker-compose-cli.yaml?

MattWilson8 (Tue, 16 Apr 2019 16:33:32 GMT):
Yes I modified it with cli: volumes: - ./../../fabric-chaincode-evm:/opt/gopath/src/github.com/hyperledger/fabric-chaincode-evm

MattWilson8 (Tue, 16 Apr 2019 16:33:42 GMT):
As stated in the tutorial

swetha (Tue, 16 Apr 2019 16:34:28 GMT):
and you are using Fabric 1.4?

MattWilson8 (Tue, 16 Apr 2019 16:34:45 GMT):
Not sure

MattWilson8 (Tue, 16 Apr 2019 16:34:52 GMT):
Is there a quick way to check that?

swetha (Tue, 16 Apr 2019 16:35:32 GMT):
if you run `docker images` you should be able to see what you have downloaded

MattWilson8 (Tue, 16 Apr 2019 16:36:35 GMT):
Right no I'm not

MattWilson8 (Tue, 16 Apr 2019 16:36:48 GMT):
Theres a lot of files but it looks like I'm using 1.2

swetha (Tue, 16 Apr 2019 16:37:49 GMT):
Hmm, okay. It should still work with 1.2 but perhaps there is something we added that doesn't

swetha (Tue, 16 Apr 2019 16:38:36 GMT):
outside of the cli container, can you run `make build` in the `fabric-chaincode-evm` repository?

MattWilson8 (Tue, 16 Apr 2019 16:39:07 GMT):

Screen Shot 2019-04-16 at 17.38.46.png

MattWilson8 (Tue, 16 Apr 2019 16:39:15 GMT):
Thats my docker images and I will try to run that now

MHBauer (Tue, 16 Apr 2019 16:39:16 GMT):
oh, what version of go is 1.2 compiled with?

MHBauer (Tue, 16 Apr 2019 16:39:33 GMT):
you know what, nah

MHBauer (Tue, 16 Apr 2019 16:39:41 GMT):
that should have been supported for years.

swetha (Tue, 16 Apr 2019 16:39:43 GMT):
Our go requirement should only affect fab3

MHBauer (Tue, 16 Apr 2019 16:40:57 GMT):
nope, I'm wrong

MHBauer (Tue, 16 Apr 2019 16:40:58 GMT):
``` ```

MHBauer (Tue, 16 Apr 2019 16:41:01 GMT):
➜ evmcc git:(master) ✗ go version go version go1.9.7 linux/amd64 ➜ evmcc git:(master) ✗ pwd /home/mhb/go/src/github.com/hyperledger/fabric-chaincode-evm/evmcc ➜ evmcc git:(master) ✗ go build # github.com/hyperledger/fabric-chaincode-evm/vendor/github.com/tmthrgd/go-hex ../vendor/github.com/tmthrgd/go-hex/hex_decode_amd64.s:66: unrecognized instruction "VPCMPGTB" ../vendor/github.com/tmthrgd/go-hex/hex_decode_amd64.s:68: unrecognized instruction "VPCMPGTB" asm: assembly of ../vendor/github.com/tmthrgd/go-hex/hex_decode_amd64.s failed ``` ```

MHBauer (Tue, 16 Apr 2019 16:41:01 GMT):
``` ➜ evmcc git:(master) ✗ go version go version go1.9.7 linux/amd64 ➜ evmcc git:(master) ✗ pwd /home/mhb/go/src/github.com/hyperledger/fabric-chaincode-evm/evmcc ➜ evmcc git:(master) ✗ go build # github.com/hyperledger/fabric-chaincode-evm/vendor/github.com/tmthrgd/go-hex ../vendor/github.com/tmthrgd/go-hex/hex_decode_amd64.s:66: unrecognized instruction "VPCMPGTB" ../vendor/github.com/tmthrgd/go-hex/hex_decode_amd64.s:68: unrecognized instruction "VPCMPGTB" asm: assembly of ../vendor/github.com/tmthrgd/go-hex/hex_decode_amd64.s failed ``` ```

MattWilson8 (Tue, 16 Apr 2019 16:41:28 GMT):
running the make build now

MHBauer (Tue, 16 Apr 2019 16:41:31 GMT):
that's evmcc deps, swetha.

swetha (Tue, 16 Apr 2019 16:41:50 GMT):
So we need at least 1.10 for evmcc as well

MHBauer (Tue, 16 Apr 2019 16:41:53 GMT):
so, yea, if 1.2 is based on go 1.19

MHBauer (Tue, 16 Apr 2019 16:42:00 GMT):
1.9*, then it won't work.

MattWilson8 (Tue, 16 Apr 2019 16:42:02 GMT):

Screen Shot 2019-04-16 at 17.42.38.png

swetha (Tue, 16 Apr 2019 16:42:17 GMT):
Okay so I think Morgan figured out the issue

MHBauer (Tue, 16 Apr 2019 16:42:20 GMT):
dang I hate go.

swetha (Tue, 16 Apr 2019 16:42:32 GMT):
The peer version of 1.2 doesn't have a go version that supports the evmcc

MHBauer (Tue, 16 Apr 2019 16:42:35 GMT):
yea, need to up to 1.3 or 1.4

swetha (Tue, 16 Apr 2019 16:42:41 GMT):
You need to upgrade your fabric images

MattWilson8 (Tue, 16 Apr 2019 16:42:47 GMT):
how would i do that?

MHBauer (Tue, 16 Apr 2019 16:42:56 GMT):
good job guys, we figured it out!

MattWilson8 (Tue, 16 Apr 2019 16:43:14 GMT):
Thanks so much I would've been lost without you both!

MHBauer (Tue, 16 Apr 2019 16:43:35 GMT):
while the go-hex guy was amenable to supporting pentium 4s, I don't think he'll care about supporting go 1.9

MHBauer (Tue, 16 Apr 2019 16:43:44 GMT):
¯\_(ツ)_/¯

swetha (Tue, 16 Apr 2019 16:43:45 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/install.html

MHBauer (Tue, 16 Apr 2019 16:44:04 GMT):
coffee break time

swetha (Tue, 16 Apr 2019 16:44:34 GMT):
Try `curl -sSL http://bit.ly/2ysbOFE | bash -s -- 1.4.0 1.4.0 0.4.15`. This should download the 1.4.0 version of all the images

swetha (Tue, 16 Apr 2019 16:44:54 GMT):
https://hyperledger-fabric.readthedocs.io/en/release-1.4/install.html

MattWilson8 (Tue, 16 Apr 2019 16:46:04 GMT):
Ok wil do

MattWilson8 (Tue, 16 Apr 2019 16:46:10 GMT):
Thanks again

MattWilson8 (Tue, 16 Apr 2019 16:48:52 GMT):
Ok so now I've downloaded the right fabric version I should be able to run the "fabric-chaincode-evm" tutorial again with more success

MattWilson8 (Tue, 16 Apr 2019 16:49:55 GMT):
I'll keep you guys updated just because the library I'm at closes in 15 mins and I need to go home and have dinner etc

swetha (Tue, 16 Apr 2019 16:52:05 GMT):
No problem

swetha (Tue, 16 Apr 2019 16:52:35 GMT):
We ran a workshop at HGF: https://www.youtube.com/watch?v=N_ulmO2-xZQ

swetha (Tue, 16 Apr 2019 16:53:15 GMT):
That is another resource that might help you

MattWilson8 (Tue, 16 Apr 2019 16:55:39 GMT):
Will give it a watch thanks!

swetha (Tue, 16 Apr 2019 16:57:38 GMT):
np!

MHBauer (Tue, 16 Apr 2019 17:11:01 GMT):
we should link that video in the reamde

MHBauer (Tue, 16 Apr 2019 17:11:12 GMT):
that's an official vedo

swetha (Tue, 16 Apr 2019 17:16:58 GMT):
oh that's true

swetha (Tue, 16 Apr 2019 17:18:05 GMT):
For those interested we are planning on having a release planning meeting for the Fabric EVM tomorrow. The event is on the community calendar. [Calendar Details] (https://calendar.google.com/calendar/event?action=VIEW&eid=NHAwNjJlaXNnc2I3Zmg4OXYyanY3cDlpcW0gc3JlcGFrdUB1cy5pYm0uY29t&tok=NzIjbGludXhmb3VuZGF0aW9uLm9yZ19uZjl1NjRnOWs5cnZkOWY4dnA0dnVyMjNiMEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tYThlMWY1MDRhMjNmMjRiNjFjZjg5Y2UwOWE4ZDM2Y2IwMjJhZWUwZg&ctz=America/Los_Angeles&hl=en&es=0)

swetha (Tue, 16 Apr 2019 17:18:05 GMT):
For those interested we are planning on having a release planning meeting for the Fabric EVM tomorrow. The event is on the community calendar. [Calendar Details](https://calendar.google.com/calendar/event?action=VIEW&eid=NHAwNjJlaXNnc2I3Zmg4OXYyanY3cDlpcW0gc3JlcGFrdUB1cy5pYm0uY29t&tok=NzIjbGludXhmb3VuZGF0aW9uLm9yZ19uZjl1NjRnOWs5cnZkOWY4dnA0dnVyMjNiMEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tYThlMWY1MDRhMjNmMjRiNjFjZjg5Y2UwOWE4ZDM2Y2IwMjJhZWUwZg&ctz=America/Los_Angeles&hl=en&es=0)

swetha (Tue, 16 Apr 2019 17:18:05 GMT):
For those interested we are planning on having a release planning meeting for the Fabric EVM tomorrow. The [event](https://calendar.google.com/calendar/event?action=VIEW&eid=NHAwNjJlaXNnc2I3Zmg4OXYyanY3cDlpcW0gc3JlcGFrdUB1cy5pYm0uY29t&tok=NzIjbGludXhmb3VuZGF0aW9uLm9yZ19uZjl1NjRnOWs5cnZkOWY4dnA0dnVyMjNiMEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tYThlMWY1MDRhMjNmMjRiNjFjZjg5Y2UwOWE4ZDM2Y2IwMjJhZWUwZg&ctz=America/Los_Angeles&hl=en&es=0)) is on the community calendar.

MHBauer (Tue, 16 Apr 2019 17:20:52 GMT):
@swetha do you have power here? I have no special rocket-chat perms

swetha (Tue, 16 Apr 2019 17:29:31 GMT):
I don't think I have power, but what were you thinking? I can try

swetha (Tue, 16 Apr 2019 17:30:06 GMT):

MHBauer (Tue, 16 Apr 2019 17:47:27 GMT):
YOU HAVE THE POWAH!

fastchain (Wed, 17 Apr 2019 03:45:11 GMT):
Hello! Is there any roadmap for a fab3 proxy development? Is there a milestone for a compatibility with web3(j,js,py) client library ? Thank you/

cbf (Wed, 17 Apr 2019 12:49:22 GMT):
there is a call today at 11 am ET Event URL: https://calendar.google.com/calendar/event?action=VIEW&eid=NHAwNjJlaXNnc2I3Zmg4OXYyanY3cDlpcW0gc3JlcGFrdUB1cy5pYm0uY29t&tok=NzIjbGludXhmb3VuZGF0aW9uLm9yZ19uZjl1NjRnOWs5cnZkOWY4dnA0dnVyMjNiMEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tYThlMWY1MDRhMjNmMjRiNjFjZjg5Y2UwOWE4ZDM2Y2IwMjJhZWUwZg&ctz=America/Los_Angeles&hl=en&es=0

guoger (Wed, 17 Apr 2019 15:03:21 GMT):
@here evm release plan meeting starts: https://zoom.us/j/6223336701

swetha (Wed, 17 Apr 2019 15:58:45 GMT):
From the discussion in the EVM call: our repo: https://github.com/hyperledger/fabric-chaincode-evm workshop: https://youtu.be/N_ulmO2-xZQ & https://youtu.be/W4HHeM61CbY

cbf (Wed, 17 Apr 2019 16:21:51 GMT):
posted the recording on the meeting page

MHBauer (Wed, 17 Apr 2019 16:21:53 GMT):
@swetha thanks for arranging the call!

MHBauer (Wed, 17 Apr 2019 16:22:02 GMT):
@cbf thanks for recording and posting!

cbf (Wed, 17 Apr 2019 16:22:10 GMT):
yep

swetha (Wed, 17 Apr 2019 22:03:13 GMT):
We will be having a monthly meeting to discuss the Fabric EVM: https://calendar.google.com/calendar/event?action=VIEW&eid=NHAwNjJlaXNnc2I3Zmg4OXYyanY3cDlpcW1fUjIwMTkwNTE1VDE1MDAwMCBzcmVwYWt1QHVzLmlibS5jb20&tok=NzIjbGludXhmb3VuZGF0aW9uLm9yZ19uZjl1NjRnOWs5cnZkOWY4dnA0dnVyMjNiMEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tMWRmZWExNTRmZTg0MTNlZjU5YTczMDAxNWYwZjc1NTVlMDk0MjY2NA&ctz=America/Los_Angeles&hl=en&es=0

swetha (Wed, 17 Apr 2019 22:03:18 GMT):

Pradeep_Pentakota (Thu, 18 Apr 2019 01:46:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=8XwodSaRKDXt4zCY3) @swetha Thanks @swetha For the link

fastchain (Thu, 18 Apr 2019 04:39:23 GMT):
@cbf Thank you for a link! Unfortunately I was not able to attend due time difference. Could you please share a link to th page with a recording? Thank you.

fastchain (Thu, 18 Apr 2019 04:48:19 GMT):
Dear all, could you please explain how can I use few addresses to interact with contract on the channel? Manual says "However we do have a mechanism to generate a user account address from the user's public key. " Since I'm working with standart(by manuals) docker setup with few nodes and few organisations, what exactly 'user's public key' means. Is it a key of the node, or something different? Thank you.

fastchain (Thu, 18 Apr 2019 04:48:19 GMT):
Dear all, is it possible to swith between orgnisation users in fab3_proxy without restart?

fastchain (Thu, 18 Apr 2019 04:48:19 GMT):
Dear all, is it possible to switch between orgnisation's users in fab3_proxy without restart?

MHBauer (Thu, 18 Apr 2019 13:25:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=dZqFvupu8mDjnrnkS) @fastchain https://wiki.hyperledger.org/display/fabric/2019-07+July+Release+Planning contains meeting data and the recording

MHBauer (Thu, 18 Apr 2019 13:26:50 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=QHcEsRFD7a7F8DtyS) @fastchain no. although multiple instances can run at the same time

MHBauer (Thu, 18 Apr 2019 17:17:47 GMT):
I updated the meeting page with notes from during the meeting: https://wiki.hyperledger.org/display/fabric/2019-07+July+Release+Planning

MHBauer (Fri, 19 Apr 2019 02:16:14 GMT):
rebasing https://gerrit.hyperledger.org/r/#/c/29149/ soon

fastchain (Fri, 19 Apr 2019 03:04:18 GMT):
@MHBauer Thank you for this links. Right now I'm figuring out how to use fabric-evm to speed up state transitions in contracts for local groups (advanced state channels). fabric-evm looks like best available option to achieve this. But there is som lack of APIs, which I'm developing by myself. Since you have "Truffle support" and "web3.py" in your plans may be we can collaborate somehow? I can push commits for review.

MHBauer (Fri, 19 Apr 2019 04:02:59 GMT):
I don't understand, but communication channels are open here if you have some ideas. We'd want to make sure we're all on the same page before you start working.

fastchain (Fri, 19 Apr 2019 05:53:36 GMT):
@MHBauer > We'd want to make sure we're all on the same page before you start working. How can I help with this? >I don't understand, but communication channels are open here if you have some ideas. what exactly should be explained?

guoger (Fri, 19 Apr 2019 07:17:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=PSR6Knce8nCgCLXbW) @fastchain I cannot understand this either... in particular, i'd appreciate if you could elaborate on: - state transition - local groups (advanced state channel) - lack of APIs (obviously all in the context of fabric and evm chaincode)

Khaled.MH (Fri, 19 Apr 2019 10:57:01 GMT):
Hello , when i try to deploy two smart contracts and make interactions between both of them, using import i find that the "import" option not yet implemented !

fastchain (Fri, 19 Apr 2019 11:12:10 GMT):
@guoger "state transition" - many transactions. For example: we have ERC20 contract where few holders(from 2 to 10) create too much transactions (it means main chain can't handle needed tnx/s rate) of operations between each other. So they can setup there's own HL network, transfer tokens with bridge service ( interledger or swaps), process transactions with acceptable speed and then write the final settlement on the mainchain (using same bridges). "local groups" - group of token holders who needs speedy transactions. "lack of APIs" - when I try to send transactions with web3py, it tries to read block Gas Limit (to check if transaction acceptable ), but there is no such field in GetBlock API, so I have to patch fab3proxy to make it work. Truffle also doesn't work "from the box". (what's happen there I've not researched yet, I can't debug JS fast ) and so on

fastchain (Fri, 19 Apr 2019 11:12:10 GMT):
@guoger "state transition" - many transactions. For example: we have ERC20 contract where few holders(from 2 to 10) create too much transactions (it means main chain can't handle needed tnx/s rate) between each other. So they can setup there's own HL network, transfer tokens with bridge service ( interledger or swaps), process transactions with acceptable speed and then write the final settlement on the mainchain (using same bridges). "local groups" - group of token holders who needs speedy transactions. "lack of APIs" - when I try to send transactions with web3py, it tries to read block Gas Limit (to check if transaction acceptable ), but there is no such field in GetBlock API, so I have to patch fab3proxy to make it work. Truffle also doesn't work "from the box". (what's happen there I've not researched yet, I can't debug JS fast ) and so on

fastchain (Fri, 19 Apr 2019 11:12:10 GMT):
@guoger "state transition" - many transactions. For example: we have ERC20 contract where few holders(from 2 to 10) create too much transactions (it means main chain can't handle needed tnx/s rate) between each other. So they can setup there's own HL network, transfer tokens with bridge service ( interledger or swaps), process transactions with acceptable speed and then write the final settlement on the mainchain (using same bridges) . By main chain I mean main Ethereum chain with POW "local groups" - group of token holders who needs speedy transactions. "lack of APIs" - when I try to send transactions with web3py, it tries to read block Gas Limit (to check if transaction acceptable ), but there is no such field in GetBlock API, so I have to patch fab3proxy to make it work. Truffle also doesn't work "from the box". (what's happen there I've not researched yet, I can't debug JS fast ) and so on

MHBauer (Fri, 19 Apr 2019 15:29:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=KxbuDepSF2KyMh4pp) @Khaled.MH I am not familiar with import, is that an opcode?

Khaled.MH (Fri, 19 Apr 2019 16:31:25 GMT):
@MHBauer import it's an option to interact a second smart contract import "SecondSmartContract.sol" import statements that are very similar to those available in JavaScript

MHBauer (Fri, 19 Apr 2019 16:34:30 GMT):
@fastchain 1. ERC20 should work. I'm not aware of the txn rate limits based on how the contracts are written. Fabric should go as fast as consensus occurs, which isn't POW based. 2. neat 3. we have blockbynumber. it'd be nice to hear about the apis you need so we can press forward and maybe integrate some of your work. truffle support is a current goal, we're not 100% there yet.

swetha (Fri, 19 Apr 2019 19:30:24 GMT):
@fastchain We don't have truffle support yet as @MHBauer said. We are working towards that. In regards to GetBlock, can you look at this jira I have created for your issue https://jira.hyperledger.org/browse/FAB-15233. Please attach logs and relevant code bits from web3.py that you think are relevant. If you have a fix you would like to submit please submit under this Jira, we would love the help!

swetha (Fri, 19 Apr 2019 19:30:24 GMT):
@fastchain We don't have truffle support yet as @MHBauer said. We are working towards that and have JIRAs open outlining what needs to be added to get that support. In regards to GetBlock, can you look at this jira I have created for your issue https://jira.hyperledger.org/browse/FAB-15233. Please attach logs and relevant code bits from web3.py that you think are relevant. If you have a fix you would like to submit please submit under this Jira, we would love the help!

swetha (Fri, 19 Apr 2019 19:33:00 GMT):
@Khaled.MH Import should work. We have tested previously. It is a solidity concept and the compiler should be dealing with the import. Fab3/EVMCC only deal with the compiled bytecode. Can you send us the sample code and a way to reproduce the error? If possible it would be great if you can open a JIRA: https://jira.hyperledger.org/projects/FAB/issues/FAB-11237?filter=allopenissues with all that information

PallabPaul (Mon, 22 Apr 2019 03:47:07 GMT):
Has joined the channel.

fastchain (Mon, 22 Apr 2019 08:49:54 GMT):
@swetha hello! since I can't comment https://jira.hyperledger.org/browse/FAB-1523 (I don't have an account), how can submit a comments? Is it OK to use github issues?

swetha (Mon, 22 Apr 2019 15:42:21 GMT):
@fastchain, We don't use Github issues. They will be automatically closed if opened. For Jira you need a linux foundation account. If you already have one you can use that to login

swetha (Mon, 22 Apr 2019 15:43:40 GMT):
You will need a Linux Foundation ID to submit changes and PRs

guoger (Mon, 22 Apr 2019 15:56:07 GMT):
> "state transition" - many transactions. For example: we have ERC20 contract where few holders(from 2 to 10) create too much transactions (it means main chain can't handle needed tnx/s rate) between each other. So they can setup there's own HL network, transfer tokens with bridge service ( interledger or swaps), process transactions with acceptable speed and then write the final settlement on the mainchain (using same bridges) . By main chain I mean main Ethereum chain with POW lightning network of some sort, implemented with Fabric?

fastchain (Tue, 23 Apr 2019 05:13:19 GMT):
@guoger hi! not lightning yet (but it's also possible), but more like interledger

AkilaVasanthakumar (Tue, 23 Apr 2019 06:01:16 GMT):
Has joined the channel.

fastchain (Tue, 23 Apr 2019 08:46:13 GMT):
@swetha hello! It looks there is a bug in response on eth_gettransactionreceipt POST / HTTP/1.1 Host: 127.0.0.1:5000 User-Agent: python-requests/2.21.0 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive Content-Type: application/json Content-Length: 148 {"jsonrpc": "2.0", "method": "eth_getTransactionReceipt", "params": ["0x29e61ce83fda0e791744050b305876b67b9a810440acfe7c0b3e12b93466f44c"], "id": 7}HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-Content-Type-Options: nosniff Date: Tue, 23 Apr 2019 08:38:31 GMT Content-Length: 383 {"jsonrpc":"2.0","result":{"transactionHash":"0x29e61ce83fda0e791744050b305876b67b9a810440acfe7c0b3e12b93466f44c","transactionIndex":"0x0","blockHash":"0xf157191f07683ceaccda1d4f40daa0f4bcd9a835137c4c9dad9285d357620a02","blockNumber":"0x24b","contractAddress":"","gasUsed":0,"cumulativeGasUsed":0,"to":"0x734138f6316c9eE4662A1FC562d20dbb3cd848fb","logs":null,"status":"0x1"},"id":7} accrording to https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gettransactionreceipt contractAddress should be null if not created (as logs in this example).

fastchain (Tue, 23 Apr 2019 08:46:13 GMT):
@swetha hello! It looks like there is a bug in response on eth_gettransactionreceipt POST / HTTP/1.1 Host: 127.0.0.1:5000 User-Agent: python-requests/2.21.0 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive Content-Type: application/json Content-Length: 148 {"jsonrpc": "2.0", "method": "eth_getTransactionReceipt", "params": ["0x29e61ce83fda0e791744050b305876b67b9a810440acfe7c0b3e12b93466f44c"], "id": 7}HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-Content-Type-Options: nosniff Date: Tue, 23 Apr 2019 08:38:31 GMT Content-Length: 383 {"jsonrpc":"2.0","result":{"transactionHash":"0x29e61ce83fda0e791744050b305876b67b9a810440acfe7c0b3e12b93466f44c","transactionIndex":"0x0","blockHash":"0xf157191f07683ceaccda1d4f40daa0f4bcd9a835137c4c9dad9285d357620a02","blockNumber":"0x24b","contractAddress":"","gasUsed":0,"cumulativeGasUsed":0,"to":"0x734138f6316c9eE4662A1FC562d20dbb3cd848fb","logs":null,"status":"0x1"},"id":7} accrording to https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gettransactionreceipt contractAddress should be null if not created (as logs in this example).

ahmedahmed (Tue, 23 Apr 2019 09:20:25 GMT):
Has joined the channel.

ahmedahmed (Tue, 23 Apr 2019 09:24:59 GMT):
hi i'm using the evm with fabric and trying to interact with deployed smart contracts using the web3 library i just built a very simple smart contract with a feature to return the sender's address like that function test() view public returns(address){ return msg.sender; } it's working fine but what i don't understand is the address i'm getting in return i never set that address and i don't know from where it's coming can anyone explain that to me and how i can change that address to set addresses i know and want to receive transactions from

fastchain (Tue, 23 Apr 2019 09:38:02 GMT):
@ahmedahmed are you calling test() method or sendiing transaction?

fastchain (Tue, 23 Apr 2019 09:39:05 GMT):
could you please show sa JS code

fastchain (Tue, 23 Apr 2019 09:48:40 GMT):
@swetha unfortunately I don't have a linux foundation account. And I don't know how to get. @MHBauer About web3py: I've created small routing proxy, to solve two problems: 1. Support of multiple accounts in one web3py instance. (the cluster of fab3 proxies is transparent for a client script) 2. To fix easely bugs in fab3 RPC without changing fab3proxy code (since I have no access anyway) . https://github.com/fastchain/fabric-chaincode-evm/blob/web3py/fab3/fab3_tooling/fab3py/router.py

fastchain (Tue, 23 Apr 2019 09:48:40 GMT):
@MHBauer @swetha unfortunately I don't have a linux foundation account. And I don't know how to get. About web3py: I've created small routing proxy, to solve two problems: 1. Support of multiple accounts in one web3py instance. (the cluster of fab3 proxies is transparent for a client script) 2. To fix easely bugs in fab3 RPC without changing fab3proxy code (since I have no access anyway) . https://github.com/fastchain/fabric-chaincode-evm/blob/web3py/fab3/fab3_tooling/fab3py/router.py

ahmedahmed (Tue, 23 Apr 2019 09:50:41 GMT):
here is my code in the js

ahmedahmed (Tue, 23 Apr 2019 09:50:43 GMT):
router.get('/test',function (req, res, next) { var web3 = new Web3(); web3.setProvider(new web3.providers.HttpProvider("http://192.168.247.129:5000")); web3.eth.defaultAccount ='0xf6209a59e758c23c7fc24ddf8ee049d9f92d72a8'; console.log(web3.eth.defaultAccount); var LoyaltyContract = web3.eth.contract(static.abiPerscription); myContract = LoyaltyContract.at(static.scAccess); var idsList = myContract.test(); res.json(idsList); });

ahmedahmed (Tue, 23 Apr 2019 09:51:28 GMT):
as you can see i set the web3.eth.defaultAccount ='0xf6209a59e758c23c7fc24ddf8ee049d9f92d72a8'; but the return result is always 0xa811ae82a805a8fd1eaa153449084e80dafdbb55

fastchain (Tue, 23 Apr 2019 09:52:04 GMT):
what is the output of web3.eth.listAccounts() ?

fastchain (Tue, 23 Apr 2019 09:52:04 GMT):
@ahmedahmed what is the output of web3.eth.listAccounts() ? try to define the caller: myContract.test().call({from: web3.eth.defaultAccount}

ahmedahmed (Tue, 23 Apr 2019 09:59:55 GMT):
i did this mySmartContract.methods.test().call({from:web3.eth.defaultAccount}, (error, result) => { if(error) res.json("error"); else res.json(result); });

ahmedahmed (Tue, 23 Apr 2019 10:00:02 GMT):
but i get that error

ahmedahmed (Tue, 23 Apr 2019 10:00:14 GMT):
Given address "" is not a valid Ethereum address

ahmedahmed (Tue, 23 Apr 2019 10:01:17 GMT):
no idea why i even tried to pass a static one and i got the same error

ahmedahmed (Tue, 23 Apr 2019 10:02:06 GMT):
and web3.eth.listAccounts() wasn't recognized as a function

fastchain (Tue, 23 Apr 2019 10:07:58 GMT):
try this web3.eth.accounts

ahmedahmed (Tue, 23 Apr 2019 10:14:29 GMT):

Clipboard - April 23, 2019 12:14 PM

ahmedahmed (Tue, 23 Apr 2019 10:14:47 GMT):

Clipboard - April 23, 2019 12:14 PM

ahmedahmed (Tue, 23 Apr 2019 11:03:18 GMT):
i think that i need to create the new account this way before using it : web3.eth.personal.newAccount(password, [callback])

ahmedahmed (Tue, 23 Apr 2019 11:04:35 GMT):
but still i have this error UnhandledPromiseRejectionWarning: Error: Node error: {"code":-32000,"message":"rpc: can't find service \"personal.NewAccount\"","data":null}

ahmedahmed (Tue, 23 Apr 2019 11:04:47 GMT):
any idea why ?

fastchain (Tue, 23 Apr 2019 11:34:26 GMT):
@ahmedahmed it's not implemented https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Fab3_Instructions.md

fastchain (Tue, 23 Apr 2019 11:35:31 GMT):
the only available key is deriveted from the user's certificate (private part) which is generated for hyperledger network

silliman (Tue, 23 Apr 2019 14:26:54 GMT):
Has left the channel.

silliman (Tue, 23 Apr 2019 14:26:59 GMT):
Has left the channel.

ahmedahmed (Tue, 23 Apr 2019 15:33:01 GMT):
do you have a document that includes all the solidity implemented features so that i can know which ones are to use and which to avoid please

MHBauer (Tue, 23 Apr 2019 15:45:21 GMT):
@fastchain this links to the information to make a linuxfoundation account https://hyperledger-fabric.readthedocs.io/en/release-1.4/Gerrit/lf-account.html#creating-a-linux-foundation-id what's needed to sign in to rocket chat? I use a lf account I think, but I suppose it could only be email

MHBauer (Tue, 23 Apr 2019 15:45:32 GMT):
oh whoa, I'm way behind

MHBauer (Tue, 23 Apr 2019 15:48:04 GMT):
@ahmedahmed details in https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Fab3_Instructions.md#eth_accounts should explain the details behind accounts.

MHBauer (Tue, 23 Apr 2019 15:48:47 GMT):
the short version is, the account is generated from the fabric keys, and there's no way to give an account as an argument.

fastchain (Wed, 24 Apr 2019 05:42:17 GMT):
@MHBauer Thank you!

fastchain (Wed, 24 Apr 2019 05:44:26 GMT):
@guoger @MHBauer @swetha Hello! I have a contract which can create different contract, and when I'm calling contract creation method I recieve this: POST / HTTP/1.1 Host: 127.0.0.1:5000 User-Agent: python-requests/2.21.0 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive Content-Type: application/json Content-Length: 249 {"jsonrpc": "2.0", "id": 34, "method": "eth_call", "params": [{"from": "0xBa3e5697A84905B7A34A3855F7E609196878F46B", "gas": "0x3d0900", "gasPrice": "0x174876e800", "to": "0x40b5ee1c640509ec975c651b41993e2183df11ae", "data": "0xa1ee8c78"}, "latest"]}HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-Content-Type-Options: nosniff Date: Wed, 24 Apr 2019 05:40:15 GMT Content-Length: 459 {"jsonrpc":"2.0","error":{"code":-32000,"message":"Failed to query the ledger: Transaction processing for endorser [peer0.org1.example.com:7051]: Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: Account/contract 40B5EE1C640509EC975C651B41993E2183DF11AE does not have permission createContract\nStack trace: [state.go:97 vm.go:105 vm.go:748 vm.go:167 vm.go:141 evmcc.go:165 handler.go:273 asm_amd64.s:2361]","data":null},"id":34}

fastchain (Wed, 24 Apr 2019 05:44:26 GMT):
@guoger @MHBauer @swetha Hello! I have a contract which can create different contract, and when I'm calling contract creation method I get this: ----- POST / HTTP/1.1 Host: 127.0.0.1:5000 User-Agent: python-requests/2.21.0 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive Content-Type: application/json Content-Length: 249 {"jsonrpc": "2.0", "id": 34, "method": "eth_call", "params": [{"from": "0xBa3e5697A84905B7A34A3855F7E609196878F46B", "gas": "0x3d0900", "gasPrice": "0x174876e800", "to": "0x40b5ee1c640509ec975c651b41993e2183df11ae", "data": "0xa1ee8c78"}, "latest"]} ----------- HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-Content-Type-Options: nosniff Date: Wed, 24 Apr 2019 05:40:15 GMT Content-Length: 459 {"jsonrpc":"2.0","error":{"code":-32000,"message":"Failed to query the ledger: Transaction processing for endorser [peer0.org1.example.com:7051]: Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: Account/contract 40B5EE1C640509EC975C651B41993E2183DF11AE does not have permission createContract\nStack trace: [state.go:97 vm.go:105 vm.go:748 vm.go:167 vm.go:141 evmcc.go:165 handler.go:273 asm_amd64.s:2361]","data":null},"id":34} Is it possible somehow to enable contracts creation? Thanks!

MHBauer (Wed, 24 Apr 2019 18:16:32 GMT):
@fastchain is it possible to get an example contract that does this? I've not done that before.

swetha (Wed, 24 Apr 2019 19:23:48 GMT):
@fastchain We currently don't allow for contracts to create other contracts. We have only allowed contract to contract invocations

swetha (Wed, 24 Apr 2019 19:25:52 GMT):
Can you explain more about the use case? We have started with the approach to be more limiting and loosen restrictions, so we are willing to make changes, but do need some feedback as why this is a feature we should support

fastchain (Thu, 25 Apr 2019 04:09:47 GMT):
@swetha hello! In may case I have multiple participants who manages different instances of the same smart contract.All this contracts are linked with each other ( for token exchange operations), so it's critical to guarantee, that each contract doesn't have any backdoors or patches. And the most convenient way to achieve this is to use "contract-producer" which can create different instances of the same smart contract . Does it makes sense? by the way, if i'll just disable the security check in the sources, will it make a trick? Or there is some deeper impact is needed? Thank you! @MHBauer https://solidity.readthedocs.io/en/v0.4.21/control-structures.html#creating-contracts

swetha (Thu, 25 Apr 2019 04:41:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=MLC4v6RskawhPpeQ8) @fastchain The code change on our side is simple. But we have to think about how to make the contract creation permission configurable. The enforcement happens in the Burrow code not the evm

swetha (Thu, 25 Apr 2019 04:41:45 GMT):
@fastchain The code change on our side is simple. But we have to think about how to make the contract creation permission configurable. The enforcement happens in the Burrow of evm code not the evmcc

swetha (Thu, 25 Apr 2019 04:43:16 GMT):
And thanks for giving that use case

klkumar369 (Thu, 25 Apr 2019 05:58:15 GMT):
Has joined the channel.

fastchain (Thu, 25 Apr 2019 06:19:35 GMT):
@swetha >The code change on our side is simple. Where and what should be changed ? (I need this info for tests) I've already tried to add permissions here https://github.com/hyperledger/fabric-chaincode-evm/blob/6404c8dc4455f63200e190b02b21f8e5f402c966/evmcc/evmcc.go#L33 and then reinstall the evmcc with (after network restart) peer chaincode install -n evmcc -l golang -v 0 -p github.com/hyperledger/fabric-chaincode-evm/evmcc but with no luck :slight_frown:

MHBauer (Thu, 25 Apr 2019 08:14:22 GMT):
that looks like the right place. if you have some tests you can share, it would help us understand what to look at and debug.

fastchain (Thu, 25 Apr 2019 10:01:43 GMT):
@MHBauer I've started a fabric/fabric-samples/first-network (in docker). And then I map my version of evmcc sources into container: root@ff2056688976:~# grep createContract /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/evmcc/evmcc.go const ContractPermFlags = permission.Call | permission.Send | createContract after this I install evmcc chaincode: peer chaincode install -n evmcc -l golang -v 0 -p github.com/fastchain/fabric-chaincode-evm/evmcc And then I do this: peer chaincode instantiate -n evmcc -v 0 -C mychannel -c '{"Args":[]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

fastchain (Thu, 25 Apr 2019 10:01:43 GMT):
@MHBauer I've started a fabric/fabric-samples/first-network (in docker). And then I map my version of evmcc sources into container: root@ff2056688976:~# grep createContract /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/evmcc/evmcc.go const ContractPermFlags = permission.Call | permission.Send | permission.CreateContract after this I install evmcc chaincode: peer chaincode install -n evmcc -l golang -v 0 -p github.com/fastchain/fabric-chaincode-evm/evmcc And then I do this: peer chaincode instantiate -n evmcc -v 0 -C mychannel -c '{"Args":[]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

fastchain (Thu, 25 Apr 2019 10:01:56 GMT):
if you need more details please ask.

compleatang (Thu, 25 Apr 2019 11:46:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=KaKsS8EAxDir4qDFc) @swetha FWIW, it's an **extremely** common pattern in EVM land to leverage "factory" contracts which are contracts that create other contracts. the children contracts are often treated as individual "objects" within the chain. as @fastchain says, this also gives assurance about the included code.

AhmedRebai (Thu, 25 Apr 2019 13:49:16 GMT):
Hi everyone i need help

AhmedRebai (Thu, 25 Apr 2019 13:49:31 GMT):
i'm getting this error when i'm deploying my smart contract

AhmedRebai (Thu, 25 Apr 2019 13:49:46 GMT):
result is{"jsonrpc":"2.0","error":{"code":-32000,"message":"rpc: can't find method \"eth.NewBlockFilter\"","data":null},"id":12}

fastchain (Thu, 25 Apr 2019 15:29:09 GMT):
@AhmedRebai https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Fab3_Instructions.md

MHBauer (Thu, 25 Apr 2019 15:44:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=txeMumb8qjf69CEHF) @fastchain the actual bytecodes/contracts. I can pull one from the solidity docs if that exactly what you're using.

MHBauer (Thu, 25 Apr 2019 15:45:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=XDHXeu8chrKWE3GYt) @AhmedRebai not implemented, I think newblockfilter is similiar to newfilter, which we are implementing.

swetha (Thu, 25 Apr 2019 17:34:12 GMT):
@compleatang thanks! I think now the question is how do tie the permissioning back to something the user can configured. Currently the way the evmcc is setup, it is an all or nothing so we need to look into that

swetha (Thu, 25 Apr 2019 17:35:50 GMT):
@fastchain The line you have is right. You need to tag on `permission.CreateContract` and possibly `permission.CreateAccount`

swetha (Thu, 25 Apr 2019 17:37:36 GMT):
Also were you able to create an LFID? As Morgan stated, it should be the same credentials you use to interact with rocket.chat

swetha (Thu, 25 Apr 2019 17:46:02 GMT):
I created a jira to track this issue: https://jira.hyperledger.org/browse/FAB-15280

swetha (Thu, 25 Apr 2019 17:53:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=jit3npHiJ8tGRM4PL) @fastchain Sorry, I missed this message earlier. Made a JIRA to track this: https://jira.hyperledger.org/browse/FAB-15281

swetha (Fri, 26 Apr 2019 02:57:06 GMT):
@fastchain I did a quick check, adding `permission.CreateContract` to https://github.com/hyperledger/fabric-chaincode-evm/blob/6404c8dc4455f63200e190b02b21f8e5f402c966/evmcc/evmcc.go#L33 allows contract to contract creation. For reference I tested against this contract: https://solidity.readthedocs.io/en/v0.5.7/contracts.html#creating-contracts. Above you had `createContract`. Not sure if that is the exact code you added, but if it is that probably is your error. If that is not it, can you send us sample contracts so we can investigate further

swetha (Fri, 26 Apr 2019 03:23:33 GMT):
@fastchain The fix I mentioned about should solve the contract creation problem. However I don't think the new contract address can be relayed back to the user yet

MHBauer (Fri, 26 Apr 2019 03:27:14 GMT):
I think the contract creating thingy has to store the new addresses.

swetha (Fri, 26 Apr 2019 03:40:02 GMT):
That would be my guess, but remix showed me something different with the vm

swetha (Fri, 26 Apr 2019 03:40:02 GMT):
That was what I thought, but remix showed me something different with the vm

swetha (Fri, 26 Apr 2019 03:45:24 GMT):
Okay, confirmed that should be the case with geth

swetha (Fri, 26 Apr 2019 03:45:41 GMT):
as reference this is the contract I use to test with: https://solidity.readthedocs.io/en/v0.5.7/contracts.html#creating-contracts

fastchain (Fri, 26 Apr 2019 04:08:37 GMT):
@swetha I've added *permission.CreateAccount* but with no luck - the behaviour is the same.

fastchain (Fri, 26 Apr 2019 04:17:28 GMT):
@swetha I've successfully logged in to Jira, thanks for clarification about the LFID.

MHBauer (Fri, 26 Apr 2019 04:20:34 GMT):
@fastchain and in combination with CreateAccount

MHBauer (Fri, 26 Apr 2019 04:20:36 GMT):
?

MHBauer (Fri, 26 Apr 2019 04:21:00 GMT):
oh nevermind

MHBauer (Fri, 26 Apr 2019 04:21:19 GMT):
issue was updated, I'll wait for a patch to think about it.

fastchain (Fri, 26 Apr 2019 04:23:36 GMT):
@MHBauer this is my permissions setup in evmcc.go const ContractPermFlags = permission.Call | permission.Send | permission.CreateContract | permission.CreateAccount

fastchain (Fri, 26 Apr 2019 04:42:06 GMT):
@MHBauer @swetha I have a feeling I'm doing something wrong because even I cut permissions with const ContractPermFlags = permission.Call in evmcc.go and restart the network (I install evmcc with *peer chaincode install -n evmcc -l golang -v 0 -p github.com/fastchain/fabric-chaincode-evm/evmcc* ) I can still create transactions and deploy contracts. What could be missing?

swetha (Fri, 26 Apr 2019 04:46:25 GMT):
You don't need permission.CreateAccount, just the permission.createContract

swetha (Fri, 26 Apr 2019 04:47:51 GMT):
Did you instantiate the evmcc? Do you have multiple versions of the evmcc installed?

swetha (Fri, 26 Apr 2019 04:47:53 GMT):
@fastchain

fastchain (Fri, 26 Apr 2019 05:01:29 GMT):
I perform following steps: 1. I setup the new netwoek with* ./byfn.sh up* (https://github.com/hyperledger/fabric-samples/blob/release-1.4/first-network/byfn.sh) 2. then a attach to *cli* container with *docker exec -it cli bash*

fastchain (Fri, 26 Apr 2019 05:01:29 GMT):
@swetha I perform the following steps: 1. I setup the new netwoek with* ./byfn.sh up* (https://github.com/hyperledger/fabric-samples/blob/release-1.4/first-network/byfn.sh) 2. then a attach to *cli* container with *docker exec -it cli bash* 3. install evmcc *peer chaincode install -n evmcc -l golang -v 0 -p github.com/fastchain/fabric-chaincode-evm/evmcc* fastchain/fabric-chaincode-evm/evmcc - patched code 4.peer chaincode instantiate -n evmcc -v 0 -C mychannel -c '{"Args":[]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem 5. running cluster of fab3 proxys FAB3_CCID="evmcc" FAB3_CHANNEL="mychannel" FAB3_CONFIG="/opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/working.yaml" FAB3_ORG="org2" FAB3_PORT="5000" FAB3_USER="User1" /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/bin/fab3 & FAB3_CCID="evmcc" FAB3_CHANNEL="mychannel" FAB3_CONFIG="/opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/working.yaml" FAB3_ORG="org2" FAB3_PORT="5001" FAB3_USER="User2" /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/bin/fab3 & .... 6.the start my tests which ends up with an exception

MHBauer (Fri, 26 Apr 2019 05:18:12 GMT):
literally the only part we care about is 6

MHBauer (Fri, 26 Apr 2019 05:18:27 GMT):
I'm not sure how many ways I can say it

MHBauer (Fri, 26 Apr 2019 05:18:33 GMT):
but what are you doing in 6

fastchain (Fri, 26 Apr 2019 06:24:35 GMT):
@MHBauer sorry for delay. Since the original smart contracts are the subject of IP, it took time to prepare a test. I've attached a script to https://jira.hyperledger.org/browse/FAB-15280

fastchain (Fri, 26 Apr 2019 06:24:35 GMT):
@MHBauer sorry for delay. Since the original smart contracts are the subject of IP, it took time to prepare a test. I've attached a test script to https://jira.hyperledger.org/browse/FAB-15280

Fias (Fri, 26 Apr 2019 06:49:50 GMT):
Has joined the channel.

ahmedahmed (Fri, 26 Apr 2019 15:23:59 GMT):
hi i want to know if it's possible to use signed transactions and if yes is it a good idea ?? thanks in advance

swetha (Fri, 26 Apr 2019 16:09:15 GMT):
@ahmedahmed fab3 currently does not allow users to pass through raw transactions that have been signed outside of fab3

ahmedahmed (Fri, 26 Apr 2019 16:33:22 GMT):
thank you but is it going to be integrated in the near future ??

swetha (Fri, 26 Apr 2019 17:30:09 GMT):
I don't think near future. We are limited currently by the functionality of the Fabric Go SDK. It is a feature we want to add, possibly later in the year

swetha (Fri, 26 Apr 2019 17:39:52 GMT):
@fastchain I will take a look at the script, but is it possible to send us the original contract?

swetha (Fri, 26 Apr 2019 17:39:52 GMT):
@fastchain I will take a look at the script

swetha (Fri, 26 Apr 2019 17:40:17 GMT):
This contract works: ``` pragma solidity ^0.5.0; contract SimpleStorage { uint storedData; function set(uint x) public { storedData = x; } function get() public view returns (uint) { return storedData; } } contract SimpleStorageCreator { event NewContract(address indexed simpleStorageAddress); function createSimpleStorage() public returns (address simpleStorageAddress){ address addr = address(new SimpleStorage()); emit NewContract(addr); return addr; } } ```

swetha (Fri, 26 Apr 2019 17:43:19 GMT):
@fastchain I tested with your contract through remix and the contract creation is successful. Can you send us the changes you made in evmcc.go again?

swetha (Fri, 26 Apr 2019 17:44:31 GMT):
This is not the cause of the problem, but we don't have a native token in fab3, so you wont be able to do this function ``` function createAndEndowD(uint arg, uint amount) public payable { // Send ether along with the creation D newD = (new D).value(amount)(arg); } ```

MHBauer (Fri, 26 Apr 2019 19:24:48 GMT):
hmn, maybe that is real root cause for generic failure.

MHBauer (Fri, 26 Apr 2019 19:25:08 GMT):
what does the failure look like for using ether? is it clear? can we improve that?

swetha (Fri, 26 Apr 2019 19:30:10 GMT):
The failure he is having doesn't have to do with that function. I am able to deploy his contract as is

swetha (Fri, 26 Apr 2019 19:30:43 GMT):
My guess is that evmcc is not updated on the peer and it is still running the old code

fastchain (Sat, 27 Apr 2019 14:14:43 GMT):
@swetha thanks, Interesting. >My guess is that evmcc is not updated on the peer and it is still running the old code I'm not an expert in HL deployment, how can I make sure I'm using patched version of evmmc? Thanks.

swetha (Sat, 27 Apr 2019 20:24:45 GMT):
@fastchain In the cli container what do you get as the output of: ``` peer chaincode list - - installed ``` and ``` peer chaincode list - - instantiated ```

swetha (Sat, 27 Apr 2019 20:24:45 GMT):
@fastchain In the cli container what do you get as the output of: ``` peer chaincode list -- installed ``` and ``` peer chaincode list -- instantiated ```

swetha (Sat, 27 Apr 2019 20:24:45 GMT):
@fastchain In the cli container what do you get as the output of: ``` peer chaincode list --installed ``` and ``` peer chaincode list --instantiated ```

swetha (Sat, 27 Apr 2019 20:25:09 GMT):
Also are you bringing down the network everytime you make a change in the evmcc?

fastchain (Sun, 28 Apr 2019 11:45:31 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=7Kgx6tJMkKEG75prJ) >Also are you bringing down the network everytime you make a change in the evmcc? I'm doing this

swetha (Sun, 28 Apr 2019 18:05:05 GMT):
Have you run `. /byfn.sh down`? In between your tests?

swetha (Sun, 28 Apr 2019 18:05:05 GMT):
Have you run `./byfn.sh down`? In between your tests?

swetha (Sun, 28 Apr 2019 18:05:25 GMT):
Have you run `. /byfn.sh down`? In between your tests?

swetha (Sun, 28 Apr 2019 18:05:51 GMT):
Were you able to run the commands I asked?

fastchain (Mon, 29 Apr 2019 02:40:15 GMT):
@swetha Hello! Yes, I've run this commands. Please see the full log here: https://pastebin.com/RQjcDdi4

fastchain (Mon, 29 Apr 2019 02:54:20 GMT):
what exactly happening during installation? It looks like there is some builder script which is setup to work with a defined git commit, but not the latest version of the sources.

swetha (Mon, 29 Apr 2019 03:33:06 GMT):
@fastchain The script is for the byfn.sh tutorial. It installs an example chaincode. I doesn't use git to my knowledge. It will install based on what is mounted into the container from the host machine. In your script you run fab3 without building. Are you building it outside of the script after your changes? You need to rebuild the binary for the changes to take effect. Also is there a reason you are running fab3 from inside the container? Another thing is I notice you are not using the fabric-chaincode-evm source code directly and a fork. Are all the changes just on your fork?

swetha (Mon, 29 Apr 2019 03:33:06 GMT):
@fastchain The script is for the byfn.sh tutorial. It installs an example chaincode. It doesn't use git to my knowledge. It will install based on what is mounted into the container from the host machine. This should not affect your test. In your script you run fab3 without building. Are you building it outside of the script after your changes? You need to rebuild the binary for the changes to take effect. Also is there a reason you are running fab3 from inside the container? Another thing is I notice you are not using the fabric-chaincode-evm source code directly and a fork. Are all the changes just on your fork?

swetha (Mon, 29 Apr 2019 03:36:06 GMT):
Can you run the peer chaincode list commands after you install the evmcc?

swetha (Mon, 29 Apr 2019 03:40:45 GMT):
And on this line of the script: `cat /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/fab3/netservice.go` can you change that to look at the evmcc.go file?

fastchain (Mon, 29 Apr 2019 03:56:25 GMT):
@swetha I'm sorry I've confused you. I missed the point that net_version is the part of fab3 proxy, but not evmcc.. >Are you building it outside of the script after your changes? No. So If I change something in evmcc.go, I have to rebuild fab3 proxy as well ? >Also is there a reason you are running fab3 from inside the container? I find it more convenient. >Another thing is I notice you are not using the fabric-chaincode-evm source code directly and a fork. Are all the changes just on your fork? Yes, all my changes just in /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm >Can you run the peer chaincode list commands after you install the evmcc? ``` root@c6d881d9017f:~# peer chaincode list -C mychannel --instantiated Get instantiated chaincodes on channel mychannel: Name: evmcc, Version: 0, Path: github.com/fastchain/fabric-chaincode-evm/evmcc, Escc: escc, Vscc: vscc Name: mycc, Version: 1.0, Path: github.com/chaincode/chaincode_example02/go/, Escc: escc, Vscc: vscc root@c6d881d9017f:~# peer chaincode list --installed Get installed chaincodes on peer: Name: evmcc, Version: 0, Path: github.com/fastchain/fabric-chaincode-evm/evmcc, Id: b8d176e63c19b5b912b8b5a35462fe7a9ef5c32ce7e0852ef2b631b9391ad5ca Name: mycc, Version: 1.0, Path: github.com/chaincode/chaincode_example02/go/, Id: e128f70653ac5518820478becd8acf4dd2b24e4e40602a307a84f0ea40871d29 ```` >And on this line of the script: `cat /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/fab3/netservice.go` can you change that to look at the evmcc.go file? https://pastebin.com/NeUG1KnW

fastchain (Mon, 29 Apr 2019 03:56:25 GMT):
@swetha I'm sorry I've confused you. I missed the point that net_version is the part of fab3 proxy, but not evmcc.. >Are you building it outside of the script after your changes? No I don't build it, I use unpatched version. So If I change something in evmcc.go, I have to rebuild fab3 proxy as well ? >Also is there a reason you are running fab3 from inside the container? I find it more convenient. >Another thing is I notice you are not using the fabric-chaincode-evm source code directly and a fork. Are all the changes just on your fork? Yes, all my changes just in /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm >Can you run the peer chaincode list commands after you install the evmcc? ``` root@c6d881d9017f:~# peer chaincode list -C mychannel --instantiated Get instantiated chaincodes on channel mychannel: Name: evmcc, Version: 0, Path: github.com/fastchain/fabric-chaincode-evm/evmcc, Escc: escc, Vscc: vscc Name: mycc, Version: 1.0, Path: github.com/chaincode/chaincode_example02/go/, Escc: escc, Vscc: vscc root@c6d881d9017f:~# peer chaincode list --installed Get installed chaincodes on peer: Name: evmcc, Version: 0, Path: github.com/fastchain/fabric-chaincode-evm/evmcc, Id: b8d176e63c19b5b912b8b5a35462fe7a9ef5c32ce7e0852ef2b631b9391ad5ca Name: mycc, Version: 1.0, Path: github.com/chaincode/chaincode_example02/go/, Id: e128f70653ac5518820478becd8acf4dd2b24e4e40602a307a84f0ea40871d29 ```` >And on this line of the script: `cat /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/fab3/netservice.go` can you change that to look at the evmcc.go file? https://pastebin.com/NeUG1KnW

fastchain (Mon, 29 Apr 2019 03:56:25 GMT):
@swetha I'm sorry I've confused you. I missed the point that net_version is the part of fab3 proxy, but not evmcc.. >Are you building it outside of the script after your changes? No I don't build it, I use unpatched version. So If I change something in evmcc.go, I have to rebuild fab3 proxy as well ? >Also is there a reason you are running fab3 from inside the container? I find it more convenient in my setup. Because of some docker issues with a network. >Another thing is I notice you are not using the fabric-chaincode-evm source code directly and a fork. Are all the changes just on your fork? Yes, all my changes just in /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm >Can you run the peer chaincode list commands after you install the evmcc? ``` root@c6d881d9017f:~# peer chaincode list -C mychannel --instantiated Get instantiated chaincodes on channel mychannel: Name: evmcc, Version: 0, Path: github.com/fastchain/fabric-chaincode-evm/evmcc, Escc: escc, Vscc: vscc Name: mycc, Version: 1.0, Path: github.com/chaincode/chaincode_example02/go/, Escc: escc, Vscc: vscc root@c6d881d9017f:~# peer chaincode list --installed Get installed chaincodes on peer: Name: evmcc, Version: 0, Path: github.com/fastchain/fabric-chaincode-evm/evmcc, Id: b8d176e63c19b5b912b8b5a35462fe7a9ef5c32ce7e0852ef2b631b9391ad5ca Name: mycc, Version: 1.0, Path: github.com/chaincode/chaincode_example02/go/, Id: e128f70653ac5518820478becd8acf4dd2b24e4e40602a307a84f0ea40871d29 ```` >And on this line of the script: `cat /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/fab3/netservice.go` can you change that to look at the evmcc.go file? https://pastebin.com/NeUG1KnW

swetha (Mon, 29 Apr 2019 04:16:51 GMT):
I am not sure what is the reason for your error. My recommendation is to restart docker itself and start fresh

swetha (Mon, 29 Apr 2019 04:17:18 GMT):
No if you make changes to the evmcc you don't need to rebuild fab3. But if you change anything in the fab3 directory you will have to rebuild.

swetha (Mon, 29 Apr 2019 04:17:21 GMT):
@fastchain

fastchain (Mon, 29 Apr 2019 04:20:04 GMT):
@swetha ok, thank you for your time and efforts! I'll try redo everything from scratch.

fastchain (Mon, 29 Apr 2019 05:25:04 GMT):
@swetha just to make it clear, this is the only line which should be changed in evmcc. go https://github.com/hyperledger/fabric-chaincode-evm/blob/master/evmcc/evmcc.go#L32 . And it's the only change that should be made?

swetha (Mon, 29 Apr 2019 05:33:19 GMT):
@fastchain yes

swetha (Mon, 29 Apr 2019 05:33:30 GMT):
It is the only change I made

swetha (Mon, 29 Apr 2019 05:33:53 GMT):
I only needed permission.CreateContract

fastchain (Mon, 29 Apr 2019 06:04:06 GMT):
@swetha It looks like I've I found a workaround. when I use evmcc2 instead of evmcc in install and instantiate commands, contract deployment works without exceptions. I don't have an explanation for such behaviour, yet.

fastchain (Mon, 29 Apr 2019 06:28:20 GMT):
Right now, I'm continuing integration tests and here is next strange issue: ``` POST / HTTP/1.1 Content-Type: application/json Connection: keep-alive Host: localhost:8080 User-Agent: Mozilla/5.0 (Linux x64) node.js/11.14.0 v8/7.0.276.38-node.18 Content-Length: 232 {"jsonrpc":"2.0","id":34,"method":"eth_call","params":[{"from":"0x52485A6876A8D7E70DD5CB2A706B7d909842A57e","gas":"0x3d0900","gasPrice":"0x174876e800","to":"0x81e7a7e1c27221c49666c7b007d79f7553f60a13","data":"0xa1ee8c78"},"latest"]} HTTP/1.0 200 OK Content-Type: application/json Content-Length: 298 Server: Werkzeug/0.15.2 Python/3.7.3 Date: Mon, 29 Apr 2019 06:18:55 GMT {"jsonrpc":"2.0","error":{"code":-32000,"message":"Failed to query the ledger: Transaction processing for endorser [peer0.org1.example.com:7051]: Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: error 16 - execution reverted: execution reverted","data":null},"id":34} ``` Could you please tell, where is the the right place to start to debuging.

swetha (Mon, 29 Apr 2019 06:48:02 GMT):
@fastchain I am not familiar with that error. It is coming from your smart contract so you need to investigate that. Remember there is no ether/native token in fabric so you have to deploy a token like a ERC 20 contract to use tokens

fastchain (Mon, 29 Apr 2019 07:11:06 GMT):
>Remember there is no ether/native token in fabric so you have to deploy a token like a ERC 20 contract to use tokens I don't use it as well. Is it possible to enable any low level EVM debug output? The function which raises this exception has calls other functions, so the exception could happen in any of them. Tests for all possible combinations could be a quite big project. So it's look reasonable to get evm traces somehow.

fastchain (Mon, 29 Apr 2019 07:11:06 GMT):
>Remember there is no ether/native token in fabric so you have to deploy a token like a ERC 20 contract to use tokens I don't use native tokens. Is it possible to enable any low level EVM debug output? The function which raises this exception has calls other functions, so the exception could happen in any of them. Tests for all possible combinations could be a quite big project. So it's look reasonable to get evm traces somehow.

fastchain (Mon, 29 Apr 2019 07:11:06 GMT):
>Remember there is no ether/native token in fabric so you have to deploy a token like a ERC 20 contract to use tokens I don't use native tokens. Is it possible to enable any low level EVM debug output? The function which raises this exception calls other functions, so the exception could be raised in any of them. Tests for all possible combinations could be a quite big project. So it's look reasonable to get evm traces somehow.

swetha (Mon, 29 Apr 2019 16:21:10 GMT):
There is no low level EVM debug at the moment. I have to think how we would do that. Maybe try debugging on remix? It should be using the same instructions

MHBauer (Mon, 29 Apr 2019 19:25:36 GMT):
like is said, we don't have too much introspection capabilitiy into the evm. Maybe try a setup of burrow directly to see if the same error occurs with that. I'll grep for the "revereted" bits

fastchain (Tue, 30 Apr 2019 11:19:03 GMT):
@MHBauer got. I'll try to do this. @swetha >Maybe try debugging on remix? It should be using the same instructions I'm using ganache testing framework and ethereum private network and contract doesn't produce exeptions( on both). I've just accidentally found that ecrecover precompiled smart contract is disabled. https://github.com/hyperledger/fabric-chaincode-evm/blob/master/vendor/github.com/hyperledger/burrow/execution/evm/native.go#L75 Is it a permanent decision?

fastchain (Tue, 30 Apr 2019 11:23:16 GMT):
Or it's a question for a #burrow channel?

fastchain (Tue, 30 Apr 2019 12:47:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=yvstr9x85WdRTsumg) I've localized the bug. It looks like (not 100% sure) burrow evm doesn't support nested contract deployment. here is the code which triggers the bug https://pastebin.com/anuNT9nX

fastchain (Tue, 30 Apr 2019 12:47:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=yvstr9x85WdRTsumg) I've localized the bug. It looks like (not 100% sure) burrow evm doesn't support nested (contract creates contract which creats contruct in constructor) contract deployment. here is the code which triggers the bug https://pastebin.com/anuNT9nX

ahmedahmed (Tue, 30 Apr 2019 13:58:24 GMT):
hi can anyone share with me an example of how to import or call a smart contract from an other that work with fabric-evm

ahmedahmed (Tue, 30 Apr 2019 13:58:34 GMT):
thanks in advance

ahmedahmed (Tue, 30 Apr 2019 14:32:14 GMT):
pragma solidity >=0.4.25 <0.6.0; contract Test1 { function doIt() public returns(string memory){ return "test!!!!!!!!!!!!!!"; } } /////////////////////

ahmedahmed (Tue, 30 Apr 2019 14:32:15 GMT):
pragma solidity >=0.4.25 <0.6.0; import "./1.sol"; contract Test2 { address accessSC = 0xdc04977a2078c8ffdf086d618d1f961b6c546222; Test1 x = Test1(accessSC); function doTest() public view returns(string){ return x.doIt(); } function doTest1() public view returns(string){ return "ok"; } }

ahmedahmed (Tue, 30 Apr 2019 14:32:56 GMT):
here is the code i was trying to do the import with but it's not working and i get this error

ahmedahmed (Tue, 30 Apr 2019 14:33:38 GMT):
Error: endorsement failure during query. response: status:500 message:"failed to execute contract: call error: RETURNDATASIZE not yet implemented"

swetha (Tue, 30 Apr 2019 15:32:34 GMT):
@ahmedahmed That error is not because of the import. You are using v0.1 and `RETURNDATASIZE` was not implemented in the version of burrow used in that version of the evmcc

swetha (Tue, 30 Apr 2019 15:32:34 GMT):
@ahmedahmed That error is not because of the import. I am assuming you are using v0.1 since `RETURNDATASIZE` was not implemented in the version of burrow used in that version of the evmcc

swetha (Tue, 30 Apr 2019 15:33:13 GMT):
It is one of the limitation of that release: https://github.com/hyperledger/fabric-chaincode-evm/blob/release-0.1/release_notes/v0.1.0.md#limitations

swetha (Tue, 30 Apr 2019 15:33:59 GMT):
You have two options, either use the newer release of the evmcc as it has a newer version of the burrow evm which has that opcode implemented

swetha (Tue, 30 Apr 2019 15:34:27 GMT):
or use a solidity compiler that is less than or equal to 0.4.21

swetha (Tue, 30 Apr 2019 15:36:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=ncvdBb3JHLo88CtKA) @fastchain Yes, they are a better channel to ask that question

swetha (Tue, 30 Apr 2019 15:41:46 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=nT8MmzGdjLLtM79he) @fastchain That will help us debug. I saw some of the conversation in the #burrow channel. Does a newer version of burrow fix the issue? From what I remember 0.24.4 to 0.25 should have no changes in the evm, which is why we didn't do an upgrade

ahmedahmed (Tue, 30 Apr 2019 15:52:01 GMT):
can u please share a link for that new version of evmcc that u know may work ?

swetha (Tue, 30 Apr 2019 16:01:07 GMT):
@ahmedahmed https://github.com/hyperledger/fabric-chaincode-evm/releases

swetha (Tue, 30 Apr 2019 16:01:23 GMT):
Sorry, meant to link this one: https://github.com/hyperledger/fabric-chaincode-evm/releases/tag/v0.2.0

swetha (Tue, 30 Apr 2019 16:02:32 GMT):
We create a tag for each release so you can do `git checkout v0.2.0`

ahmedahmed (Tue, 30 Apr 2019 16:14:58 GMT):
thanks a lot just one more question if i pull this git repository : https://github.com/hyperledger/fabric-chaincode-evm would it contain that last version of evmcc ?

swetha (Tue, 30 Apr 2019 16:32:34 GMT):
the default branch is master

swetha (Tue, 30 Apr 2019 16:45:31 GMT):
when you clone a repository you should get all the branches, tags currently on the remote

MHBauer (Tue, 30 Apr 2019 19:12:50 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=22AgYmg6uRH43RoBL) @swetha this is more work than I was thinking. get filters has three types of returns based on the filter type created.

swetha (Tue, 30 Apr 2019 21:04:57 GMT):
@MHBauer can you break it into smaller pieces like how you tackled getLogs?

MHBauer (Tue, 30 Apr 2019 21:16:08 GMT):
of course, but the point is it's multiple interacting bits, some of which were not planned.

swetha (Tue, 30 Apr 2019 21:31:13 GMT):
All the filtering is a big piece, at least as i understood it. I was expecting it would take time to get it all in

MHBauer (Tue, 30 Apr 2019 23:43:15 GMT):
Yea, for all filtering. Was hoping to be done with just logs in place.

MHBauer (Tue, 30 Apr 2019 23:43:29 GMT):
need to re-evaluate some thoughts for blocks and txns

fastchain (Wed, 01 May 2019 03:37:33 GMT):
@swetha Hello! how can I use newer version of borrow in evmcc? Just clone it in fabric-chaincode-evm/vendor/github.com/hyperledger/burrow or something else? thanks.

MHBauer (Wed, 01 May 2019 04:12:34 GMT):
you'd have to update the dep, with dep, the program.

MHBauer (Wed, 01 May 2019 04:12:50 GMT):
and then fix everything that breaks

MHBauer (Wed, 01 May 2019 04:17:02 GMT):
and we'd be interested in doing that, or having it eventually, but it's not a priority right now if we don't have a bug or demonstration/test to justify doing so.

swetha (Wed, 01 May 2019 05:41:01 GMT):
@fastchain Morgan gave the overview of the process and we would love a patch if you can make one. Did you try the test Casey mentioned against the different versions of Burrow to verify the error?

fastchain (Wed, 01 May 2019 06:25:11 GMT):
@swetha hello! I've built the most recent version of borrow, the executed the test, but the test has failed. Details are here https://github.com/hyperledger/burrow/pull/1102

fastchain (Wed, 01 May 2019 06:46:45 GMT):
@MHBauer got it. >and then fix everything that breaks do you have test set do identify broken?

fastchain (Wed, 01 May 2019 06:46:45 GMT):
@MHBauer got it. >and then fix everything that breaks do you have test set to identify broken?

fastchain (Wed, 01 May 2019 06:46:45 GMT):
@MHBauer got it. >and then fix everything that breaks is there any tests to identify broken?

fastchain (Wed, 01 May 2019 06:46:45 GMT):
@MHBauer got it. >and then fix everything that breaks are there any tests to identify broken?

MHBauer (Wed, 01 May 2019 18:06:10 GMT):
I mostly mean compilation errors, but if anything deep has changed, it should be very very obvious.

MHBauer (Wed, 01 May 2019 18:06:31 GMT):
`make checks integration-test` should do everything we'll need for a successful checkin

swetha (Wed, 01 May 2019 18:35:30 GMT):
@fastchain My recommendation is to first make sure the tests with burrow passes before upgrading it in the evmcc. We want to make sure that the new version of burrow has the fix you need before pulling it in

MHBauer (Wed, 01 May 2019 18:37:44 GMT):
^that

ahmedahmed (Thu, 02 May 2019 18:05:35 GMT):

Screenshot from 2019-05-02 11-01-12.png

ahmedahmed (Thu, 02 May 2019 18:05:38 GMT):
hi i'm trying to run fab3 i just cloned the latest version of fabric-evm so i run this command "make fab3" and it generated a fab3 file but when i run to execute it i get this error can anyone help me with that

MHBauer (Thu, 02 May 2019 18:07:33 GMT):
you have to give it your sdk config so it can connect to a faric network where the chaincode is running.

ahmedahmed (Thu, 02 May 2019 18:10:30 GMT):
yeah thanks for your quick answer that was exactly the problem THANK YOU :D

MHBauer (Thu, 02 May 2019 18:10:54 GMT):
very welcome

ahmedahmed (Fri, 03 May 2019 10:12:25 GMT):
hi i'm trying to use events and logs with fabric-evm so i wrote this code to get me the logs but i'm not getting anything back var myEvent = myContract.birthCertifcateEvent({}, {fromBlock: 0, toBlock: 'latest'}); myEvent.get((error, response)=> { return res.json(response); });

ahmedahmed (Fri, 03 May 2019 10:13:11 GMT):
actually it just keeps on loading nothing no errors or results

ahmedahmed (Fri, 03 May 2019 13:15:45 GMT):

Clipboard - May 3, 2019 3:14 PM

swetha (Fri, 03 May 2019 15:58:21 GMT):
@ahmedahmed my guess is that the function on the backend is using asynchronous filters on the backend that we don't support yet. Try sending a request for get logs

swetha (Fri, 03 May 2019 15:59:33 GMT):
In your screenshot lines 11-15 are the indexed topics of your event

swetha (Fri, 03 May 2019 16:00:25 GMT):
Line 12 should be the keccek sum of your event signature

swetha (Fri, 03 May 2019 16:01:40 GMT):
Is your screenshot the request or response?

ahmedahmed (Fri, 03 May 2019 16:32:11 GMT):
this screenshot is for myContract.birthCertifcateEvent({}, {fromBlock: 0, toBlock: 'latest'});

ahmedahmed (Fri, 03 May 2019 16:37:53 GMT):
i tried this var myEvent = myContract.birthCertifcateEvent({}, {fromBlock: 'earliest', toBlock: 'latest'}).get(x=>{}); res.json(myEvent); and as a result i got the following response

ahmedahmed (Fri, 03 May 2019 16:38:17 GMT):

Clipboard - May 3, 2019 6:38 PM

ahmedahmed (Fri, 03 May 2019 16:39:13 GMT):
i added the call back in the get() because it was required

ahmedahmed (Fri, 03 May 2019 16:46:04 GMT):
other ways when u suggested that i send a request for get logs what did u mean exactly sry because i didn't

MHBauer (Fri, 03 May 2019 16:54:31 GMT):
we think the backend code uses async filters https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_newfilter which aren't supported yet. supported filters for logs is https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getlogs

ahmedahmed (Fri, 03 May 2019 17:00:44 GMT):
ok so it's not possible to get the logs using the web3 library because it's asynchronous ?

MHBauer (Fri, 03 May 2019 18:00:29 GMT):
not unless you can tune it

MHBauer (Fri, 03 May 2019 18:00:31 GMT):
to use that.

MHBauer (Fri, 03 May 2019 18:00:45 GMT):
otherwise it still needs to be implemented.

swetha (Fri, 03 May 2019 18:13:43 GMT):
@ahmedahmed until it is implemented try using web3.eth.getBlock or web3.eth.getTransactionReceipt. Those should have the logs for your contract as well

swetha (Fri, 03 May 2019 18:14:30 GMT):
otherwise you can hit the fab3 yourself with the method eth_getLogs: https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Fab3_Instructions.md#eth_getlogs

MHBauer (Fri, 03 May 2019 19:09:13 GMT):
8uyy;'

ahmedahmed (Sat, 04 May 2019 06:08:31 GMT):
thanks again for your help that was very constructive for me :D

ahmedahmed (Sat, 04 May 2019 13:27:02 GMT):
hello again this time i'm trying to create a factory smart contract like this but the problem whenever i call the function that creates the new smart contract i get this error generic error: Account/contract EBAB35950F82D7F8C93B87F9F622350829B64108 does not have permission createContract

ahmedahmed (Sat, 04 May 2019 13:30:00 GMT):
contract Bakery { // index of created contracts address[] public contracts; // useful to know the row count in contracts index function getContractCount() public constant returns(uint contractCount) { return contracts.length; } // deploy a new contract function newCookie() public returns(address newContract) { Cookie c = new Cookie(); contracts.push(c); return c; } } contract Cookie { // suppose the deployed contract has a purpose function getFlavor() public constant returns (string flavor) { return "mmm ... chocolate chip"; } }

ahmedahmed (Sat, 04 May 2019 13:32:20 GMT):

Clipboard - May 4, 2019 3:28 PM

ahmedahmed (Sat, 04 May 2019 13:33:46 GMT):

Clipboard - May 4, 2019 3:26 PM

ahmedahmed (Sat, 04 May 2019 13:36:26 GMT):
actually EBAB35950F82D7F8C93B87F9F622350829B64108 is the address of the smart conract i deployed to be the factory

swetha (Sat, 04 May 2019 17:25:09 GMT):
@ahmedahmed currently there is not support for contract creation through a contract. There is a discussion above on how to achieve that if you are want that feature: https://chat.hyperledger.org/channel/fabric-evm?msg=GMgtiHfpKwtvm9Kjs

swetha (Sat, 04 May 2019 17:25:09 GMT):
@ahmedahmed currently there is not support for contract creation through a contract. There is a discussion above on how to achieve that if you want that feature: https://chat.hyperledger.org/channel/fabric-evm?msg=GMgtiHfpKwtvm9Kjs

alexmatson (Sun, 05 May 2019 22:01:24 GMT):
Has joined the channel.

fastchain (Mon, 06 May 2019 05:47:18 GMT):
@swetha Hello Is there any way to get a version of burrowEVM used in chaincodeevm build ? thank you!

fastchain (Mon, 06 May 2019 06:30:13 GMT):
@MHBauer I've updated burrow EVM in evmcc, but with no luck: 1. I've download a compatible version of solc (according to burrow manual) make bin/solc 2. created version of contract which runs in last available version of burrow. (there is some issue with msg.sender variable, so I just removed this variable) ``` pragma solidity ^0.5.1; contract D { //address x; constructor() public payable { //x =z; } } contract X { //address z; constructor() public payable { D d = new D(); } } contract C { function createD() public { X newX = new X(); } } ``` 3. Moved the latest available version (dev branch) of burrow to the vendor folder in fabric-chaincode-evm. 4. Ran test compilation of evmmc make bin/evmcc with no issues. 4. Launched a new network ./byfn.sh down ./byfn.sh up 5. Installed evmmc ``` peer chaincode install -n evmcc2 -l golang -v 0 -p github.com/fastchain/fabric-chaincode-evm/evmcc ``` 6. Initiated evmmc ``` peer chaincode instantiate -n evmcc2 -v 0 -C mychannel -c '{"Args":[]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem ``` 7. Launched fab3 proxy ``` FAB3_CCID="evmcc2" FAB3_CHANNEL="mychannel" FAB3_CONFIG="/opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/working.yaml" FAB3_ORG="org2" FAB3_PORT="5000" FAB3_USER="User1" /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/bin/fab3 `` 8. Tried to deploy contract and got the same exception ``` {'code': -32000, 'message': 'Failed to execute transaction: Transaction processing for endorser [peer0.org1.example.com:7051]: Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: error 16 - execution reverted: execution reverted', 'data': None} ``` it looks like an issue could be somewhere at the junction.. Do you have any Ideas what to do next? Thanks. ```

fastchain (Mon, 06 May 2019 06:30:13 GMT):
@MHBauer I've updated burrow EVM in evmcc, but with no luck: 1. I've download a compatible version of solc (according to burrow manual) make bin/solc 2. created version of contract which runs in last available version of burrow. (there is some issue with msg.sender variable, so I just removed this variable) ``` pragma solidity ^0.5.1; contract D { //address x; constructor() public payable { //x =z; } } contract X { //address z; constructor() public payable { D d = new D(); } } contract C { function createD() public { X newX = new X(); } } ``` 3. Moved the latest available version (dev branch) of burrow to the vendor folder in fabric-chaincode-evm. 4. Ran test compilation of evmmc make bin/evmcc with no issues. 4. Launched a new network ./byfn.sh down ./byfn.sh up 5. Installed evmmc ``` peer chaincode install -n evmcc2 -l golang -v 0 -p github.com/fastchain/fabric-chaincode-evm/evmcc ``` 6. Initiated evmmc ``` peer chaincode instantiate -n evmcc2 -v 0 -C mychannel -c '{"Args":[]}' -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem ``` 7. Launched fab3 proxy ``` FAB3_CCID="evmcc2" FAB3_CHANNEL="mychannel" FAB3_CONFIG="/opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/working.yaml" FAB3_ORG="org2" FAB3_PORT="5000" FAB3_USER="User1" /opt/gopath/src/github.com/fastchain/fabric-chaincode-evm/bin/fab3 ``` 8. Tried to deploy contract and got the same exception ``` {'code': -32000, 'message': 'Failed to execute transaction: Transaction processing for endorser [peer0.org1.example.com:7051]: Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: error 16 - execution reverted: execution reverted', 'data': None} ``` it looks like an issue could be somewhere at the junction.. Do you have any Ideas what to do next? Thanks.

MHBauer (Mon, 06 May 2019 16:22:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=smLg9NxCMF8k3PvbR) @fastchain burrow details https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Gopkg.toml#L9-L10

MHBauer (Mon, 06 May 2019 16:22:30 GMT):
I assume we can still check out that tag of burrow and run it.

swetha (Mon, 06 May 2019 19:05:34 GMT):
We use 0.24.4, https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Gopkg.toml#L8-L10. As Morgan said you should be able to checkout that tag in burrow or that release and test using their binaries

swetha (Mon, 06 May 2019 19:06:43 GMT):
In regards to the steps you outlined above, you don't need to download the solc binary when using the fabric evm because we don't compile contracts. Burrow has a deploy tool that will compile contracts which is why they ask you to download solc, which is only necessary if you are testing against a burrow node

fastchain (Mon, 06 May 2019 23:08:33 GMT):
@swetha hello! >In regards to the steps you outlined above, you don't need to download the solc binary when using the fabric evm because we don't compile contracts. I understand. I used solc to compile a contract to check that contract's bytecode works in burrow standalone setup. And then I used this code for bmcc chaincode deployment. @MHBauer thanks for this tip!

fastchain (Mon, 06 May 2019 23:12:19 GMT):
@MHBauer thanks! this file Gopkg.toml is used during *make bin/evmcc* operation only, or during *peer chaincode install -n evmcc2 -l golang -v 0 -p github.com/fastchain/fabric-chaincode-evm/evmcc* as well?

swetha (Mon, 06 May 2019 23:19:04 GMT):
@fastchain that file is used only during development when updating dependencies or ensuring dependencies are correct

MHBauer (Mon, 06 May 2019 23:20:06 GMT):
you were asking for the version, that's where "what version we have" is written down.

MHBauer (Mon, 06 May 2019 23:20:23 GMT):
it's processed by dep, the tool https://github.com/golang/dep

MHBauer (Mon, 06 May 2019 23:24:50 GMT):
and so, to start your upgrade process, i'd expect something like `dep ensure -update github.com/hyperledger/burrow@0.25.0` or edit the toml and then run `dep ensure`

Jasonyou (Tue, 07 May 2019 00:11:07 GMT):
Has joined the channel.

fahadkheratker (Tue, 07 May 2019 06:43:16 GMT):
Has joined the channel.

fahadkheratker (Tue, 07 May 2019 08:30:48 GMT):
Hello, each time a eth smart contract over fabric-chaincode-evm is invoked , three transaction are added to the block chain

fahadkheratker (Tue, 07 May 2019 08:31:00 GMT):
can anybody tell me the significance of the same?

fahadkheratker (Tue, 07 May 2019 08:31:22 GMT):
and the correct way to filter these transactions?

fahadkheratker (Tue, 07 May 2019 08:33:05 GMT):
i have an event listener listening my blockchain transactions, need to filter transactions over fabric-chaincode-evm accordingly

Ulysses (Tue, 07 May 2019 08:46:05 GMT):
Has joined the channel.

fastchain (Tue, 07 May 2019 09:00:39 GMT):
@MHBauer I've ```dep ensure -update -v``` with ``` [[constraint]] version = "0.25.0" name = "github.com/hyperledger/burrow" ``` in Gopkg.toml and then relaunched network. with no luck ``` Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: error 16 - execution reverted: execution reverted', 'data': None ``` :head_bandage:

fastchain (Tue, 07 May 2019 09:00:39 GMT):
@MHBauer I've ```dep ensure -update -v ``` with ``` [[constraint]] version = "0.25.0" name = "github.com/hyperledger/burrow" ``` in Gopkg.toml and then relaunched network. with no luck ``` Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: error 16 - execution reverted: execution reverted', 'data': None ``` :head_bandage:

fastchain (Tue, 07 May 2019 09:00:39 GMT):
@MHBauer I've ``` dep ensure -update -v ``` with ``` [[constraint]] version = "0.25.0" name = "github.com/hyperledger/burrow" ``` in Gopkg.toml and then relaunched network. with no luck ``` Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: error 16 - execution reverted: execution reverted', 'data': None ``` :head_bandage:

swetha (Tue, 07 May 2019 18:25:59 GMT):
What are the 3 transactions? There should only be one transaction per evmcc invocation

swetha (Tue, 07 May 2019 18:27:31 GMT):
We have a couple problems here in debugging. I am not clear that the Burrow update will solve your problem, so until we solve that we won't know if the problem is that the bug is still there or if the code change is taking effect, as this was a problem earlier for you

swetha (Tue, 07 May 2019 18:27:58 GMT):
@fastchain ^^

swetha (Tue, 07 May 2019 18:28:08 GMT):
@fahadkheratker ^^

MHBauer (Tue, 07 May 2019 22:08:44 GMT):
looks like rocket does threading now.

fastchain (Tue, 07 May 2019 23:50:12 GMT):
here are filtered logs from container docker logs peer0.org1.example.com -f 2>&1 | grep -via gossip | grep -via discovery https://pastebin.com/vuG6KaAi does it make any sense? >so until we solve that we won't know if the problem is OK. I'll roll back to 24

swetha (Wed, 08 May 2019 00:10:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=ttoQQnoSRvwML27R7) the logs don't really show what the problem is. I don't think 24 versus 25 is the problem. If we are able to verify that burrow in general results in the same thing or doesn't that will help us narrow down the search

swetha (Wed, 08 May 2019 00:11:04 GMT):
In the burrow channel I think sean gave some ideas as to what caused the error. do any of those apply?

fastchain (Wed, 08 May 2019 01:30:29 GMT):
You mean this message https://chat.hyperledger.org/channel/burrow?msg=nJ3Ggm9pCRPypRqMD ?

fastchain (Wed, 08 May 2019 01:30:29 GMT):
Do you mean this message ? https://chat.hyperledger.org/channel/burrow?msg=nJ3Ggm9pCRPypRqMD ?

swetha (Wed, 08 May 2019 01:56:48 GMT):
yes that's the one

guoger (Wed, 08 May 2019 01:57:38 GMT):
UI is a bit odd tho...

MHBauer (Wed, 08 May 2019 01:57:50 GMT):
very weird

guoger (Wed, 08 May 2019 01:58:38 GMT):
looks like rocket does threading now.

fastchain (Wed, 08 May 2019 02:51:46 GMT):
it looks like none of this is applicable to test contract :( is there any way to get a debug output from burrow when it runs with evmcc ?

fastchain (Wed, 08 May 2019 02:51:46 GMT):
it looks like none of this is applicable to the test contract :( is there any way to get a debug output from burrow when it runs with evmcc ?

fastchain (Wed, 08 May 2019 03:40:00 GMT):
Dear all. Is there any way to forward an evmcc debug log to the stdout (to read with 'docker logs')?

fastchain (Wed, 08 May 2019 03:40:00 GMT):
Dear all, Is there any way to forward an evmcc debug log to the stdout (to read with 'docker logs')?

fastchain (Wed, 08 May 2019 04:34:40 GMT):
to get this kind of messages https://github.com/hyperledger/burrow/blob/c44fbec9feab53f2e537ddde830505fea90e6f98/deploy/jobs/jobs_contracts.go#L478

MHBauer (Wed, 08 May 2019 06:19:09 GMT):
not as it is. you'd have to do research to figure out how to hook it up.

MHBauer (Wed, 08 May 2019 06:19:19 GMT):
look for `var evmLogger = logging.NewNoopLogger()`

MHBauer (Wed, 08 May 2019 06:26:21 GMT):
if you can figure out a way to shoehorn the flogging logger , or just implement it with fmt.Println() you'll get output to docker logs.

MHBauer (Wed, 08 May 2019 06:35:47 GMT):
looking back through the code, the vm doesn't have a lot of log entries

MHBauer (Wed, 08 May 2019 06:38:06 GMT):
if you want the opcodes, you can look for

MHBauer (Wed, 08 May 2019 06:38:08 GMT):
vm := evm.NewVM(newParams(), callerAddr, nonce, evmLogger)

MHBauer (Wed, 08 May 2019 06:38:20 GMT):
and then add after it

MHBauer (Wed, 08 May 2019 06:38:22 GMT):
evm.DebugOpcodes(vm)

MHBauer (Wed, 08 May 2019 06:38:48 GMT):
and if you want even more, find in burrow code

MHBauer (Wed, 08 May 2019 06:38:48 GMT):
// Uncomment for quick and dirty debug //fmt.Printf(format, a...)

MHBauer (Wed, 08 May 2019 06:38:52 GMT):
and uncomment it

MHBauer (Wed, 08 May 2019 06:39:45 GMT):
you'll need to implement the logger for the first one to work.

klenik (Wed, 08 May 2019 11:11:51 GMT):
Hi All! I've run into some strange behavior that I can't really explain, could you give me some insights about the EVMCC and EVM interaction? Full disclosure: I'm using a [modified EVMCC](https://github.com/aklenik/caliper/blob/fabric-evm/src/adapters/fabric-ccp/src/evmcc/evmcc.go) which exposes the `value` and `nonce` variables to the caller (and some extra timing logs). But the core logic is the same, plus I don't use the value, just the nonce in the next scenario. So the scenario is the following. I have a simple token contract that has a `transfer` function with an additional `balances` backing field/map and using safemath. The gist of the relevant code is this: ``` mapping(address => uint256) public balances; function transfer(address _receiver, uint256 _value) public returns (bool) { require(_value > 0 && balances[msg.sender] >= _value); balances[msg.sender] = balances[msg.sender].sub(_value); balances[_receiver] = balances[_receiver].add(_value); return true; } ``` Nothing interesting so far. I have two version of this contract

fahadkheratker (Wed, 08 May 2019 11:27:44 GMT):
@swetha my application network is down at the moment ill get back to you with the same issue asap

fahadkheratker (Wed, 08 May 2019 11:28:33 GMT):
Also does any one know how to convert the fabric evm payload to readable string?

fahadkheratker (Wed, 08 May 2019 11:28:33 GMT):
\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\003\350

klenik (Wed, 08 May 2019 12:00:24 GMT):
@fahadkheratker I use [this](https://github.com/ethereumjs/ethereumjs-abi) npm package on the client side to encode/decode arguments/results

klenik (Wed, 08 May 2019 12:00:46 GMT):
@MHBauer @swetha Hi All! This will be long, sorry :) I've run into some strange behavior and I can't really explain what I see, so could you give me some insights about the EVMCC and EVM interactions? Continued in the thread below, since now we have this awesome feature.

klenik (Wed, 08 May 2019 12:01:01 GMT):
Full disclosure: I'm using a [modified EVMCC](https://github.com/aklenik/caliper/blob/fabric-evm/src/adapters/fabric-ccp/src/evmcc/evmcc.go) which exposes the `value` and `nonce` variables to the caller (and some extra timing logs). But the core logic is the same, plus I don't use the value, just the nonce in the next scenario. So the scenario is the following. I have a simple token contract that has a `transfer` function with an additional `balances` backing field/map and using SafeMath. The gist of the relevant code is this: ``` using SafeMath for uint256; mapping(address => uint256) public balances; function transfer(address _receiver, uint256 _value) public returns (bool) { require(_value > 0 && balances[msg.sender] >= _value); balances[msg.sender] = balances[msg.sender].sub(_value); balances[_receiver] = balances[_receiver].add(_value); return true; } ``` Nothing interesting so far. I have two versions of this contract, C1 and C2, but their transfer functions are identical (their whole bytecode is not). I have 2 Fabric identities/certs (client[1|2]). I test C1 and C2 independently, on totally clean and separate Fabric networks, but with the same identities (that's why I exposed the nonce, so the contract address generation and the nonce passed to the EVM can be deterministic). The contracts and identities got the same addresses in both tests, I've verified this. I can deploy both contracts successfully, and client1 get a lot of token in the constructor. Now I call transfer on a clean system with client1: transfer 1000 tokens to client2. And it works in both cases, but there's something strange going on under the hood. Namely, the two contract calls produce a different writeset, but a same readset. In both cases, there are 3 matching reads (across C1 and C2): 1. `calleeCode := evmCache.GetCode(calleeAddr)` in EVMCC, with the `contract address` as the key, at version `2.0` (1st block: instantiate EVMCC; 2nd block: deploy EMV contract, so the version comes from this). I assume this read is produced by `statemanager.GetAccount`, based on the key. 2-3: `balances[msg.sender]` and `balances[_receiver]` also produce 1-1 reads (the other access calls are answered from the EVM State's cache). First part of the key is the contract address, plus an extra part, guessing it's the map's key encoded somehow. Guessing these reads are produced by `statemanager.GetStorage`. And so far still good, it returns a version 2.0 answer and a nil, since the second user has 0 tokens, hence not in the map at this point. Regarding the write set, there are 3 writes: 1-2: Setting `balances[msg.sender]` and `balances[_receiver]` produces 1-1 write, with matching keys and values (across C1 and C2). 3. However, there's a 3rd write, with the contract address as the key, and a really long value (in hex encoded form, 7116 characters for C1 and 7072 for C2). I guess it's produced by `statemanager.UpdateAccount`. What does this 3rd write represents? The map-related storages are already updated by the previous reads. Plus the two value are almost identical, apart from the length and randomly distributed hex characters around the end... So what happens here? Functionally, from the client's POV, everything is fine, but this write set difference really botheres me, especially since I don't know where it comes from and everything else matches. Both execution should be deterministic, as ensured by the manually provided nonces. I've arrived to the following hypothesis by the time I've finished writing this message: the entire Account object is updated/saved, which includes the bytecode of the contract, which is different, hence the different write value. Can someone confirm this? I don't see the bytecode directly in the written value, but I guess Account.Encode() can obscure it somehow.

swetha (Wed, 08 May 2019 15:59:56 GMT):
If you are using the peer cli, unfortunately no there is no way to really decode that. Try using fab3, ir takes care of the the encoding to make it in hex

swetha (Wed, 08 May 2019 15:59:56 GMT):
If you are using the peer cli, unfortunately no there is no way to really decode that. Try using fab3, it takes care of the the encoding to make it in hex

swetha (Wed, 08 May 2019 16:04:54 GMT):
I believe that is correct. There was also a difference in how Burrow dealt with writes so the two releases of the evm will have different writes. I am assuming you are using the same version of the EVM in both cases.

swetha (Wed, 08 May 2019 16:05:12 GMT):
So that is probably not the situation

swetha (Wed, 08 May 2019 16:08:49 GMT):
I would have to verify by the opcodes to see where that 3rd write is being generated from. Callstate in the burrow code will use the EVMCC statemanger: https://github.com/hyperledger/burrow/blob/v0.24.4/execution/evm/vm.go#L226-L991

ahmedahmed (Thu, 09 May 2019 09:46:53 GMT):
hi do you think that the use of fabric-evm add an other level of security to fabric because it stores the smart contract in the ledger and not outside of it like regular chain codes is that true ?

MHBauer (Thu, 09 May 2019 17:32:24 GMT):
too big for a thread

MHBauer (Thu, 09 May 2019 17:32:35 GMT):
this whole conversation is like one inch wide and nine pages long

swetha (Thu, 09 May 2019 17:37:11 GMT):
Why do you feel that is another level of security? They are two different approaches, I don't necessarily think one is more secure over the other. Are you worried about the code been changed when it is on the file system? Because the fabric system, through the endorsement policy, will ensure that everyone is arriving to the same answer

swetha (Thu, 09 May 2019 17:37:33 GMT):
we can try the discussion option next time. They apparently create sub channels

MHBauer (Thu, 09 May 2019 17:38:42 GMT):
this tells me we should do more logging in the evmcc,

MHBauer (Thu, 09 May 2019 17:38:50 GMT):
so we can see all the writes.

MHBauer (Thu, 09 May 2019 17:39:17 GMT):
@klenik it's too much work to figure out what changed in your fork of the code.

MHBauer (Thu, 09 May 2019 17:39:39 GMT):
@klenik is the evm contracts/bytecode in the repo as well?

MHBauer (Thu, 09 May 2019 17:39:49 GMT):
would help us repro and triage eventually

klenik (Fri, 10 May 2019 10:06:59 GMT):
@MHBauer @swetha I'll put together a MWE tomorrow with the crypto materials, contract sources and bytecodes, and I'll try to reproduce the issue(?) in the original evmcc

swetha (Fri, 10 May 2019 15:07:43 GMT):
That would be great!

MHBauer (Fri, 10 May 2019 17:40:36 GMT):
What's great?

swetha (Fri, 10 May 2019 18:39:53 GMT):
oh that was in response to the thread. It looks like app on the phone doesn't distinguish between the channel and the thread

swetha (Fri, 10 May 2019 18:40:02 GMT):
That would be great!

MHBauer (Fri, 10 May 2019 19:07:55 GMT):
neat

Ulysses (Mon, 13 May 2019 02:46:21 GMT):
hi, everyone, i'm confused about that can i interact with a smart contract which is not deployed on fabric-evm? Sorry for my stupid question and

Ulysses (Mon, 13 May 2019 02:52:56 GMT):
Hi, i'm confused about that can i interact with a smart contact which is *not* deployed on EVMCC ? Sorry for my stupid question and grungy English

MHBauer (Mon, 13 May 2019 06:13:46 GMT):
WHat is "I"?

MHBauer (Mon, 13 May 2019 06:14:14 GMT):
evm contracts have no concept of fabric to be able to interact with them.

umtyzc (Mon, 13 May 2019 07:05:58 GMT):
Has joined the channel.

umtyzc (Mon, 13 May 2019 07:09:11 GMT):
Hi, I ran “go build -o fab3 ./fabproxy/cmd” , but give a error “assembly of vendor hex_decode_amd64.s failed”. Can you help me for this problem?

Ulysses (Mon, 13 May 2019 07:20:19 GMT):
@MHBauer Sorry:sweat_smile: Can a smart contact deployed on EVMCC interact with a smart contact deployed on Ethereum？

swetha (Mon, 13 May 2019 11:47:26 GMT):
@Ulysses , no a smart contract deployed on EVMCC cannot interact with a smart contract deployed on ethereum. The EVMCC only allows portability of ethereum contracts and dapps

swetha (Mon, 13 May 2019 11:48:06 GMT):
@umtyzc What version of go are you using?

umtyzc (Mon, 13 May 2019 12:43:15 GMT):
Hi swetha, go version 1.9.2

swetha (Mon, 13 May 2019 15:39:57 GMT):
@umtyzc Fab3 requires at least Go 1.10 to compile. Here are the requirements: https://github.com/hyperledger/fabric-chaincode-evm#current-dependencies. Also the version you are using seems older as the code you are referring to has fabproxy in it. I recommend updating to our most recent release or master

umtyzc (Mon, 13 May 2019 15:46:20 GMT):
Thanks @swetha

Ulysses (Tue, 14 May 2019 01:54:39 GMT):
Thanks for your help @swetha

fahadkheratker (Tue, 14 May 2019 07:12:15 GMT):
how can i view logs of evmcc

fahadkheratker (Tue, 14 May 2019 07:12:19 GMT):
?

ahmedahmed (Tue, 14 May 2019 10:20:43 GMT):
i asked this question earlier here is a link https://chat.hyperledger.org/channel/fabric-evm?msg=zaHjfKp2oWoycsFYy

ahmedahmed (Tue, 14 May 2019 10:21:51 GMT):
i have a question: is it possible to change the gas value ?? if yes how or in which file is it set ??

fahadkheratker (Tue, 14 May 2019 10:44:02 GMT):
Yeah it would be great if we had a way to logs fabric evm

ahmedahmed (Tue, 14 May 2019 11:34:51 GMT):
i have a question: is it possible to change the gas value ?? if yes how or in which file is it set ??

fahadkheratker (Tue, 14 May 2019 11:36:54 GMT):
Also One more query, is there a way to update fabric-evm - (evmcc) whenever a new version is released

swetha (Tue, 14 May 2019 12:30:54 GMT):
@fahadkheratker there are currently not too many logs produce from the evmcc yet. But if you want those logs you can find them, depending on your setup, by getting logs of the container that is running the evmcc.

swetha (Tue, 14 May 2019 12:31:32 GMT):
If you are looking for logs/events that are produced from your contracts, we don't yet support asynchronous event support. But the events are consumable through the eth_getLogs method

swetha (Tue, 14 May 2019 12:33:16 GMT):
In terms of updating the evmcc, we currently don't make the versions compatible with each other, which means updating might not work if there have been changes in the data model. In general though you should be able to upgrade any chaincode by installing the new version and then running a `peer chaincode update` command

swetha (Tue, 14 May 2019 12:34:14 GMT):
I believe for right not, v0.1 of the evmcc cannot be upgraded to v0.2

swetha (Tue, 14 May 2019 12:35:23 GMT):
@ahmedahmed No it is not possible to change the gas value dynamically. Right now it is hardcoded here: https://github.com/hyperledger/fabric-chaincode-evm/blob/master/evmcc/evmcc.go#L91. Why do you want to change the gas value? Is the value too small?

swetha (Tue, 14 May 2019 12:35:53 GMT):
We made it very high to ensure that transactions should have enough gas to complete

ahmedahmed (Tue, 14 May 2019 12:43:07 GMT):
actually i have a smart contract that is a bit big i'm using web3 to deploy the smart contract by passing the byte code

swetha (Tue, 14 May 2019 12:59:00 GMT):
Just curious, what gas limit do you need for your smart contract to work? Typically would you deploy a contract that big on the ethereum network?

swetha (Tue, 14 May 2019 12:59:33 GMT):
@ahmedahmed ^^

ahmedahmed (Tue, 14 May 2019 13:19:54 GMT):
when i tested the smart contract in remix the default gas limit value : 3000000 was not enough so i had to set it to 4000000 and in some cases 5000000

MHBauer (Tue, 14 May 2019 17:08:12 GMT):
I was gonna say that 10k doesn't seem like a lot, but burrow has everything valued at 1.

MHBauer (Tue, 14 May 2019 19:17:28 GMT):
@swetha Oh man, we have a meeting tomorrow morning. Gonna be short, I think.

swetha (Tue, 14 May 2019 19:59:39 GMT):
@MHBauer I have a conflict tomorrow, so won't be able to attend

fahadkheratker (Wed, 15 May 2019 05:26:08 GMT):
@swetha thanks for your response, we are planning to use fabric-evm in our production application, however if there are any updates in the evm or any fixes or changes we would mostly like to get an update of that as well if the versions are not compatible we will be unable to do so. Please comment on this query!

fahadkheratker (Wed, 15 May 2019 05:27:14 GMT):
Also i get that fabric-evm cannot be updated at the moment but what about solidity smartcontract can they be updated over the evm? for eg smartcontract.sol (v1) can be upgraded to smartcontract.sol (v2)

umtyzc (Wed, 15 May 2019 08:36:35 GMT):
Hi, I want to assign assign loyalty contract with web3 using the contract's ABI. LoyaltyContract = web3.eth.contract(LoyaltyABI) Error = Reference error loyaltyABI not defined.

umtyzc (Wed, 15 May 2019 08:38:16 GMT):
Solved. [ ](https://chat.hyperledger.org/channel/fabric-evm?msg=3g7wWslhRFf1AilCjC)

klenik (Wed, 15 May 2019 08:40:38 GMT):
@MHBauer Hmm, this is an interesting fact, thx. Do you know by any chance what was the reasoning behind this? It's strange that everything matches the EVM yellow paper specification, except the gas costs of operations :thinking:

umtyzc (Wed, 15 May 2019 08:52:58 GMT):
Now, I want to create a new member using web-app. Can you help? Failed to query the ledger: Transaction processing for endorser [localhost:7051]: Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: call error: Invalid jump dest

ahmedahmed (Wed, 15 May 2019 10:43:19 GMT):
hi fabric is taking more and more space on my hard disk i tried shutting down the network and creating a new one but still i can't recover any space is possible that some files or docker images need to be removed manually ??

fahadkheratker (Wed, 15 May 2019 11:41:34 GMT):
yes

fahadkheratker (Wed, 15 May 2019 11:41:38 GMT):
clear docker cahc

fahadkheratker (Wed, 15 May 2019 11:41:40 GMT):
cache*

fahadkheratker (Wed, 15 May 2019 11:41:47 GMT):
using docker system prune

ahmedahmed (Wed, 15 May 2019 11:53:04 GMT):
thanks @fahadkheratker but i have a running network is going to go down or i'm i going to lose the config if i run docker system prune ???

ahmedahmed (Wed, 15 May 2019 12:07:03 GMT):
i tried docker system prune -a nothing much happened :(

fahadkheratker (Wed, 15 May 2019 12:11:50 GMT):
what is your system config?

swetha (Wed, 15 May 2019 12:34:47 GMT):
@fahadkheratker no, a solidity smart contract can't be upgraded. Its the same situation as in Ethereum

swetha (Wed, 15 May 2019 12:35:29 GMT):
@umtyzc I am not sure what you are trying. I need more information about what you are calling.

swetha (Wed, 15 May 2019 12:36:21 GMT):
@ahmedahmed docker prune should not affect anything is running

umtyzc (Wed, 15 May 2019 12:41:18 GMT):
I am trying to implement loyalty-points-evm-fabric example. @swetha I have reached the last step. I can start the dapp.js application on localhost:8000 but give a error.

umtyzc (Wed, 15 May 2019 12:43:05 GMT):
Error details: Failed to query the ledger: Transaction processing for endorser [localhost:7051]: Chaincode status Code: (500) UNKNOWN. Description: failed to execute contract: call error: Invalid jump dest

swetha (Wed, 15 May 2019 12:55:47 GMT):
What is the actual command you are trying to run that causes that error

lehors (Wed, 15 May 2019 14:54:15 GMT):
@swetha do you actually plan to have the call today? I'm guessing not, given that you're at Consensus...

lehors (Wed, 15 May 2019 14:54:29 GMT):
https://wiki.hyperledger.org/display/fabric/Fabric+Chaincode+EVM

swetha (Wed, 15 May 2019 15:27:18 GMT):
@MHBauer should be running it

MHBauer (Wed, 15 May 2019 18:07:25 GMT):
I panicked. Computer crashed and i couldn't get it to start,, so I went in to "get ready to go in to work mode" and failed to consider the obvious solution of "use my own personal computer" until I got to work here. I apologize.

MHBauer (Wed, 15 May 2019 18:08:12 GMT):
I think our main update right now, is we don't have enough time to work on this in relation to trying to fill gaps on fabric 2.0.

fahadkheratker (Thu, 16 May 2019 09:45:50 GMT):
any idea how to debug evmcc?

fahadkheratker (Thu, 16 May 2019 12:32:02 GMT):

Clipboard - May 16, 2019 6:01 PM

swetha (Thu, 16 May 2019 12:51:11 GMT):
Seems like your application isn't able to connect to the peer

fahadkheratker (Fri, 17 May 2019 05:05:52 GMT):
any idea on how do we debug the above issue?

fahadkheratker (Fri, 17 May 2019 05:06:04 GMT):
also is there nay way to debug evmcc?

fahadkheratker (Fri, 17 May 2019 05:06:52 GMT):

ethereum-get-set.zip

fahadkheratker (Fri, 17 May 2019 06:02:54 GMT):
I have also setup a channel based even listener on my channel to listen to my blocks and to detect changes to ledger

fahadkheratker (Fri, 17 May 2019 06:03:07 GMT):
the following is the output of the chain code

fahadkheratker (Fri, 17 May 2019 06:03:32 GMT):

fahadkheratker - Fri May 17 2019 11:33:13 GMT+0530 (India Standard Time).txt

fahadkheratker (Fri, 17 May 2019 06:05:37 GMT):
There are three blocks During invoking of Block 1 , i had initialised value "ab" to "fahad" and as you can see there are two values in the write state, the first value i do not know what it is, the second value is my data.

fahadkheratker (Fri, 17 May 2019 06:07:24 GMT):
then when invoking block 2 i updated "ab" to "fahad v2" and there were three entries in the write states , 1st unclear value [ chaincode data maybe], second value is blank and the 3rd value is my data

fahadkheratker (Fri, 17 May 2019 06:07:24 GMT):
then when invoking block 2 i updated "ab" to "fahad v2" and there were three entries in the write states , 1st unknown value [ chaincode data maybe], second value is blank and the 3rd value is my data

fahadkheratker (Fri, 17 May 2019 06:09:09 GMT):
then when invoking the 3rd block i updated "ab" to "" and there are three states again , 1st unknown value [ chaincode data maybe], second value is blank and third value is the key "ab" with some unknown string

fahadkheratker (Fri, 17 May 2019 06:10:42 GMT):
@swetha can you please check the chain code and the write state and explain me why is this happening and what is happening and give some clarity towards the process

fahadkheratker (Fri, 17 May 2019 06:12:58 GMT):
we have a channel based block listener that reads writes states to determine what value is added in the block chain such that we do not have to query the block chain everytime and have a record of all transaction and states.

fahadkheratker (Fri, 17 May 2019 06:13:14 GMT):
Please look in to this.

MHBauer (Fri, 17 May 2019 22:45:04 GMT):
what has your listener to do with the question?

MHBauer (Fri, 17 May 2019 22:45:20 GMT):
The reads are the reads and the writes are the writes. It's how the chaincode works.

circlespainter (Sat, 18 May 2019 07:41:02 GMT):
Has joined the channel.

fahadkheratker (Sat, 18 May 2019 11:03:02 GMT):
You can check the listener output and see what the evm is writing

fahadkheratker (Sat, 18 May 2019 11:09:44 GMT):
the thing is when i am setting the property ab to blank during the third write the value that is written to the ledger is the name of the property that is ab with some added string

fahadkheratker (Sat, 18 May 2019 11:09:49 GMT):
i dont understand this behavior

swetha (Mon, 20 May 2019 04:39:11 GMT):
@fahadkheratker I haven't had time to dig through. Quick glance the 3 keys seem to make sense. I believe the first is the contract account, the second is the mapping in which you are storing the keys in your contract, and the third is the key,value pair in the mapping of which you are altering

swetha (Mon, 20 May 2019 05:06:35 GMT):
After you do the third block and you query the key value is ab returning something other than blank?

fahadkheratker (Mon, 20 May 2019 05:13:45 GMT):
yes

fahadkheratker (Mon, 20 May 2019 05:15:54 GMT):
this is what is written in the second block's last write states "value": "Fahadv2\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u000e"

fahadkheratker (Mon, 20 May 2019 05:16:21 GMT):
and the below is written in the third block's last write state "value": "ab\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000"

fahadkheratker (Mon, 20 May 2019 05:21:36 GMT):
as you can see Fahadv2 is replaced by the property name itself in the last block

fahadkheratker (Mon, 20 May 2019 05:21:46 GMT):
shouldnt it be blank insteaD?

fahadkheratker (Mon, 20 May 2019 05:22:15 GMT):
and what is this value "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000" what encoding is this , is this garbage value?

swetha (Mon, 20 May 2019 05:27:43 GMT):
okI think `"\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000` is just a series of empty bytes

swetha (Mon, 20 May 2019 05:27:51 GMT):
are you using the peer cli?

swetha (Mon, 20 May 2019 05:28:17 GMT):
basically you are getting the raw bits back, you should encode into hex

fahadkheratker (Mon, 20 May 2019 05:30:56 GMT):
yes i am using peer cli

fahadkheratker (Mon, 20 May 2019 05:33:25 GMT):
post encoding to hex how to convert it into readable string?

swetha (Mon, 20 May 2019 05:42:15 GMT):
you have to use the sdk

swetha (Mon, 20 May 2019 05:42:27 GMT):
or when you query you can provide `--hex'

swetha (Mon, 20 May 2019 05:42:27 GMT):
or when you query you can provide `--hex`

swetha (Mon, 20 May 2019 05:42:46 GMT):
but recommendation is to use an sdk to interact with the evmcc

swetha (Mon, 20 May 2019 05:42:46 GMT):
but recommendation is to use an sdk to interact with a fabric network

swetha (Mon, 20 May 2019 05:43:00 GMT):
for the evmcc specifically use fab3

fahadkheratker (Mon, 20 May 2019 05:44:43 GMT):
we are using node sdk can we do it with that?

swetha (Mon, 20 May 2019 05:46:27 GMT):
yes

swetha (Mon, 20 May 2019 05:46:44 GMT):
you an do that and do everything manually

swetha (Mon, 20 May 2019 05:46:44 GMT):
you can do that and do everything manually

swetha (Mon, 20 May 2019 05:46:58 GMT):
or you can use fab3, which allows you to use ethereum clients like remix or web3.js

fahadkheratker (Mon, 20 May 2019 05:56:41 GMT):
actually we already have a lot of micro services up and running so we are avoiding fab3 implementation.

fahadkheratker (Mon, 20 May 2019 05:57:07 GMT):
we have already manually implemented the code to invoke and query from our peers directly

fahadkheratker (Mon, 20 May 2019 05:57:21 GMT):
only this remaining is to convert this raw data into readable data

swetha (Mon, 20 May 2019 06:19:02 GMT):
then you can do it using the node sdk

swetha (Mon, 20 May 2019 06:19:18 GMT):
just change the encoding of the returned values of your invokes and queries

klenik (Mon, 20 May 2019 08:38:20 GMT):
@fahadkheratker I use the following npm package to encode and decode arguments and return values https://www.npmjs.com/package/ethereumjs-abi Pros: just supply the "readable" values plus the param/return part of the solidity method signature, and the package will encode/decode it according to the solidity spec (handling even complex structures)

gregdhill (Mon, 20 May 2019 11:14:48 GMT):
Has joined the channel.

fahadkheratker (Mon, 20 May 2019 12:42:06 GMT):
@klenik thanks

fahadkheratker (Mon, 20 May 2019 12:42:27 GMT):
@swetha i have successfully decoded the payloads on node

fahadkheratker (Mon, 20 May 2019 12:44:14 GMT):
however still unsure about the value that is written in the third block. It should be blank but instead the key name is being written in the last state of the third block

fahadkheratker (Mon, 20 May 2019 12:44:21 GMT):
why is it so?

swetha (Mon, 20 May 2019 18:23:51 GMT):
the last block is storing both the key and the value

swetha (Mon, 20 May 2019 18:23:56 GMT):
the value in this case is empty bytes

swetha (Mon, 20 May 2019 18:24:00 GMT):
the key is ab

fahadkheratker (Tue, 21 May 2019 04:38:58 GMT):
any particular reason for this behaviour?

fahadkheratker (Tue, 21 May 2019 04:39:15 GMT):
as all blocks are only storing the value of the keys

fahadkheratker (Tue, 21 May 2019 04:39:40 GMT):
only the last block is saving both the key and value when blank value is assigned

fahadkheratker (Tue, 21 May 2019 05:21:13 GMT):
whenever a blank value is set , the key value both are stored in the write state.

fahadkheratker (Tue, 21 May 2019 05:21:16 GMT):
why is it so?

fahadkheratker (Tue, 21 May 2019 05:21:20 GMT):
can you please help?

MHBauer (Tue, 21 May 2019 20:23:51 GMT):
@fahadkheratker that's what the burrow evm gives as writes. We're passing whatever it does through.

fahadkheratker (Wed, 22 May 2019 09:32:27 GMT):
@swetha there is an issue, i have set up the fab3 server and the web3 client, then i deployed the solidity smart contract below and tried to set a blank value to a property (A) of object called "state" of type "mapping", the service was successfully executed, however when i tried to retrieve the same property again through web3 and fab3 setup my client broke. and in the "Write States" the name of the property was saved instead of a blank value this is indeed a bug. as my fab3 and web3 client also broke when querying this.

fahadkheratker (Wed, 22 May 2019 09:32:29 GMT):
pragma solidity ^0.4.0; contract GetSetContract{ mapping (string => string) state; event StateSaveEvent(string key, string value); function get(string memory key) public view returns(string) { string memory value = state[key]; require(!equal(value, '')); return value; } function set(string memory key, string memory value) public { state[key] = value; emit StateSaveEvent(key, value); } function compare(string _a, string _b) internal returns (int) { bytes memory a = bytes(_a); bytes memory b = bytes(_b); uint minLength = a.length; if (b.length < minLength) minLength = b.length; for (uint i = 0; i < minLength; i ++) if (a[i] < b[i]) return -1; else if (a[i] > b[i]) return 1; if (a.length < b.length) return -1; else if (a.length > b.length) return 1; else return 0; } function equal(string _a, string _b) internal returns (bool) { return compare(_a, _b) == 0; } }

fahadkheratker (Wed, 22 May 2019 09:32:58 GMT):

ethereum-get-set.zip

MHBauer (Wed, 22 May 2019 14:06:38 GMT):
you know there's a require that's supposed to crash it when it's a blank value?

MHBauer (Wed, 22 May 2019 14:08:24 GMT):
additionally, I'm still not sure if this can run require.

swetha (Wed, 22 May 2019 14:09:07 GMT):
@fahadkheratker were you having issues when you tried this just with the peer cli or the node sdk?

swetha (Wed, 22 May 2019 14:12:45 GMT):
and what is the error you are seeing?

MHBauer (Thu, 23 May 2019 01:51:39 GMT):
@klenik any update on your fork-ish to make a caliper bench?

fahadkheratker (Thu, 23 May 2019 05:33:15 GMT):
@swetha fab3 package

swetha (Thu, 23 May 2019 17:11:31 GMT):
@fahadkheratker What is the error you are seeing? As @MHBauer pointed out, your contract will error when get something that is blank

swetha (Thu, 23 May 2019 17:11:31 GMT):
@fahadkheratker What is the error you are seeing? As @MHBauer pointed out, your contract will error when you get something that is blank

klenik (Thu, 23 May 2019 20:10:00 GMT):
@MHBauer My fork-ish was a quick-and-not-so-dirty integration, so it'll be some time (2 weeks maybe) before I can add it to the Caliper repo. (But it will be a nice addition, an Ethereum adapter is also WIP, and Burrow has some initial support, so the EVM will be covered from every angle soon :P )

swetha (Thu, 23 May 2019 20:38:04 GMT):
@klenik very cool! looking forward to seeing that

Ulysses (Fri, 24 May 2019 01:49:10 GMT):
Hi everyone, how can smart contract(deployed on Fabric) written in solidity invoke chaincode?

MHBauer (Fri, 24 May 2019 01:56:37 GMT):
Cannot.

MHBauer (Fri, 24 May 2019 01:57:01 GMT):
evm can only talk to evm

Ulysses (Fri, 24 May 2019 02:06:42 GMT):
:no_mouth:

Ulysses (Fri, 24 May 2019 02:10:03 GMT):
Thank you for helping me .

MHBauer (Fri, 24 May 2019 02:11:47 GMT):
think about it realistically, tho. What concept of fabric has the evm? How would an evm call fabric?

guoger (Mon, 03 Jun 2019 03:06:54 GMT):
wasm intern 2019 summer

guoger (Mon, 03 Jun 2019 03:07:54 GMT):
wasm intern 2019 summer

hyper-sunder (Wed, 05 Jun 2019 05:05:39 GMT):
Has left the channel.

MHBauer (Wed, 19 Jun 2019 14:59:21 GMT):
https://wiki.hyperledger.org/display/fabric/Fabric+Chaincode+EVM meeting very soon

lehors (Wed, 19 Jun 2019 15:05:56 GMT):
nobody wants to say hi to you...

lehors (Wed, 19 Jun 2019 15:12:10 GMT):
you're not on mute but we like to make you suffer thinking you might be ;-)

kenty (Wed, 17 Jul 2019 02:25:23 GMT):
Has joined the channel.

annumberhocker (Fri, 02 Aug 2019 18:37:45 GMT):
Has joined the channel.

conanoc (Tue, 13 Aug 2019 08:50:32 GMT):
Has joined the channel.

madiazp (Thu, 22 Aug 2019 08:31:04 GMT):
Has joined the channel.

madiazp (Thu, 22 Aug 2019 08:38:16 GMT):
Hi, I've got a "error 9 - call stack overflow: int64 overflow from word: ��l " from the evmcc.go when it use the call method https://github.com/hyperledger/fabric-chaincode-evm/blob/master/evmcc/evmcc.go#L148, is that bc of the smartcontract code being too large? or the arguments? or something else that I'm missing?

madiazp (Thu, 22 Aug 2019 08:40:40 GMT):
the function in the smartcontract is something like this dd129313": "verifyTx(uint256[2],uint256[2][2],uint256[2],uint256[1]), and I don't want to paste the smartcontract code but is pretty large

swetha (Mon, 26 Aug 2019 18:09:17 GMT):
@madiazp I am taking a look. Sorry for the delay

madiazp (Mon, 26 Aug 2019 22:32:17 GMT):
@swetha No problem, I've got this answere from the burrow team https://github.com/hyperledger/burrow/issues/1224

madiazp (Mon, 26 Aug 2019 22:33:09 GMT):
It will be really good if I (We) can see the logs from burrow

swetha (Mon, 26 Aug 2019 22:33:17 GMT):
@madiazp Oh great that they responded

madiazp (Mon, 26 Aug 2019 22:33:29 GMT):
"We have an option that would help you debug which opcode caused the error: https://github.com/hyperledger/burrow/blob/develop/execution/evm/options.go#L11-L13 but it looks like fabric-evm doesn't currently expose any switch to make that run."

swetha (Mon, 26 Aug 2019 22:33:46 GMT):
Adding an option for burrow logs is on our list

madiazp (Mon, 26 Aug 2019 22:33:54 GMT):
Nice!

swetha (Mon, 26 Aug 2019 22:34:15 GMT):
We haven't gotten to it yet, unfortunately

swetha (Mon, 26 Aug 2019 22:34:27 GMT):
Were you able to get to the core of your issue?

MHBauer (Mon, 26 Aug 2019 22:34:28 GMT):
I think the issue was it just dumped it on stdout, and isn't configurable.

madiazp (Mon, 26 Aug 2019 22:35:09 GMT):
Not yet, today I will run the test told by the burrow team

MHBauer (Mon, 26 Aug 2019 22:35:22 GMT):
:+1:

madiazp (Mon, 26 Aug 2019 22:36:38 GMT):
If I get something weird I would let you know

madiazp (Mon, 26 Aug 2019 22:36:47 GMT):
(in the test)

madiazp (Mon, 26 Aug 2019 22:36:56 GMT):
will*

swetha (Mon, 26 Aug 2019 23:02:00 GMT):
I am also experimenting with the logs. If there is a quick way for you to enable it locally I will let you know as well

madiazp (Mon, 26 Aug 2019 23:03:06 GMT):
that would be great, thanks

MHBauer (Mon, 26 Aug 2019 23:45:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=JYgt8PB8amCqdiFm4) this code irritates me. there's a way to turn it on, but not off...

MHBauer (Mon, 26 Aug 2019 23:46:11 GMT):
I do retract the previous statement I made about stdout logging, they appear to log to a logger now.

MHBauer (Mon, 26 Aug 2019 23:49:41 GMT):
I suppose we always use a fresh instance of the vm, so, it could be made into a startup configuration, or read from the ledger. Bit difficult.

swetha (Tue, 27 Aug 2019 00:33:57 GMT):
@madiazp Here is a commit I added on my fork that turns on the logging in burrow: https://github.com/swetharepakula/fabric-chaincode-evm/commit/27a43d5ff4e2b9c3eb72f70a5314393cd66731e0

swetha (Tue, 27 Aug 2019 00:34:09 GMT):
As Morgan mentioned, there is no way to turn it off currently

swetha (Tue, 27 Aug 2019 00:34:55 GMT):
To get those changes, I recommend installing the evmcc again with the logging changes with a new version and then upgrading the evmcc to the new version. That should turn on the logging for you

madiazp (Tue, 27 Aug 2019 02:00:21 GMT):
Oh thanks a lot, I would try to do a merge in my local repo, I've changed a lot of things for my purposes

madiazp (Tue, 27 Aug 2019 02:00:36 GMT):
will* again

guoger (Tue, 27 Aug 2019 02:03:19 GMT):
@swetha do we want to migrate to github?

swetha (Tue, 27 Aug 2019 02:06:07 GMT):
@guoger yes we should

guoger (Tue, 27 Aug 2019 02:06:46 GMT):
is the github pipeline thing free? or we need to coordinate with LF to sort out CI

swetha (Tue, 27 Aug 2019 02:18:28 GMT):
Are we still sticking with jenkins?

swetha (Tue, 27 Aug 2019 02:18:56 GMT):
I believe pipeline is free for open source/public projects?

guoger (Tue, 27 Aug 2019 02:37:08 GMT):
that's how i understand it, so no jenkins, but azure pipelines

MHBauer (Tue, 27 Aug 2019 19:26:21 GMT):
azure pipeline?

MHBauer (Tue, 27 Aug 2019 19:26:28 GMT):
I just got access to the github version

MHBauer (Tue, 27 Aug 2019 19:26:36 GMT):
not sure I can share that access

madiazp (Wed, 28 Aug 2019 00:28:11 GMT):
Hi again. So it was the amount of gas https://github.com/hyperledger/fabric-chaincode-evm/blob/master/evmcc/evmcc.go#L87. I've put a random value var gas uint64 = 10123122000 and kind of worked (I had no output but I think is related to the smart contract and not the fabric-cc-evm, and it ran successfully without error)

vikas.kundz (Wed, 28 Aug 2019 05:07:31 GMT):
Has joined the channel.

swetha (Wed, 28 Aug 2019 20:47:29 GMT):
@madiazp that's great! Interesting error though. I am used to see a not enough gas error for that situation

swetha (Wed, 28 Aug 2019 20:48:09 GMT):
Are most of the smart contracts that you write a similar size which would require gas limits higher than 90000?

swetha (Wed, 28 Aug 2019 20:48:09 GMT):
Are most of the smart contracts that you write a similar size which would require gas limits higher than 10000?

madiazp (Wed, 28 Aug 2019 20:58:36 GMT):
the sc that I used in this case it was one auto generated by ZoKrates https://github.com/Zokrates/ZoKrates. I'm really new with smart contract but the tiny ones that I made to test fabric-cc-evm worked just fine. The smart contracts generated by ZoKrates are really large bc of the zk-SNARK implementations.

madiazp (Wed, 28 Aug 2019 21:02:36 GMT):
but yeah it was odd to me too. I'll make more test about gas and why throw an overflow instead of a "not enough gas" error

madiazp (Thu, 29 Aug 2019 01:39:14 GMT):
Here is a more detailed update https://github.com/hyperledger/burrow/issues/1224#issuecomment-525984271

conanoc (Thu, 29 Aug 2019 09:50:01 GMT):
I have two questions about fabric-evm. 1. evmcc is replacing "from account" or caller address to the creater's ID. This creater's ID will be the ID of Fab3 and it is strange that Fab3 replaces the caller address with it's own address. Some Ethereum Dapp will not work if it's JSON-RPC proxy replaces the caller address. For example, Ethereum wallet will not able to send ERC20 tokens to other accounts using Fab3. Is there any reason why Fab3 replaces the caller addess? 2. Ethereum Dapps usually send signed transaction to the proxy and this ensures that the transaction is valid and it will not be modified in the middle until it is included in the block. evmcc does not seem to check the signature of the transaction, and it does not save the transaction as the original form. It's a problem because it executes the transaction without validation and the stored transaction cannot be verified that it's not tampered.

swetha (Thu, 29 Aug 2019 20:23:57 GMT):
@conanoc 1. So in this case Fab3 would be connected to your wallet. When you start up you indicate the identity that you want to use. Fab3 does not actually replace the address. It just removes whatever is provided because the EVM gets the address by the submitting signature. Fab3 will sign the transaction with the identity you have chosen to use and from the signature the EVM on the fabric node will be able to determine the caller address. So there is no way to actually insert an caller address. We currently do not support Ethereum wallets. One of the biggest reasons is because the certificate algorithms are different from Ethereum and Fabric so the certs cannot be shared. 2. Fab3 does not have the ability to send signed transactions. One of the blocks for this is that the underlying fabric client (fabric-go-sdk) does not accept signed transactions yet. When the feature is added, there will need to be some thought on design because of the differences in Ethereum and Fabric certs. By the time the transaction comes to the EVMCC, the fabric node has already verified the signature of the transactions. And for the transaction to be added to a block, various nodes must generate the same read write sets. Each node would be verifying the transaction signature

madiazp (Thu, 29 Aug 2019 20:49:00 GMT):
when I submit a smart contract to the ledger via the ZeroAddress, it get added in the chain right? so other smart contract in the chain can use it? for example If I submit a solidity library as a smart contract another smart contract could import it with its address.

swetha (Thu, 29 Aug 2019 20:57:03 GMT):
@madiazp That is correct

conanoc (Fri, 30 Aug 2019 02:45:17 GMT):
@swetha Thanks for your explanation. I think fabric transaction can just embed ethereum transaction as data and treat ethereum as one of the apps using fabric. fabric-evm could support ethereum wallets if evmcc does not replace the caller account. You mentioned that certificate algorithms are different from Ethereum and Fabric, but why do they have be the same? The thing fabric-evm has to do with the ethereum signature is to validate the signature of the ethereum transaction. As for the transaction added in the block, Ethereum Dapps will only care whether it's the same transaction as the one they submitted and if it can be verified with the signature attached in the transaction that it's not tamperd.

swetha (Fri, 30 Aug 2019 03:06:31 GMT):
@conanoc The algorithms don't necessarily need to be the same, but an ethereum identity is not associated to anything on the fabric side. It would mean the EVMCC would have added functionality about storing ethereum certs, and need to do the validation, which is already being done by the Fabric Peer. Saying that, we have thought about the approach you have mentioned, but have not settled on how to handle it. Questions that come up is whether that ethereum identity/certificate can be anonymous, which is different from Fabric. If we say ethereum identity needs to be connected to a fabric identity, it means maintaining two types of identity management. Ethereum Dapps would still be able to see it as the same transaction, as the caller address will be the same as the identity that signed the transaction to begin with. It would only be different if the Dapp tried to put in a callee address that it was not using to sign the transaction. I am also curious to understand the use case of needed an ethereum certificate over using the fabric one? What are the benefits gained?

swetha (Fri, 30 Aug 2019 03:06:31 GMT):
@conanoc The algorithms don't necessarily need to be the same, but an ethereum identity is not associated to anything on the fabric side. It would mean the EVMCC would have added functionality about storing ethereum certs, and need to do the validation, which is already being done by the Fabric Peer. Saying that, we have thought about the approach you have mentioned, but have not settled on how to handle it. Questions that come up is whether that ethereum identity/certificate can be anonymous, which is different from Fabric. If we say ethereum identity needs to be connected to a fabric identity, it means maintaining two types of identity management. Ethereum Dapps would still be able to see it as the same transaction, as the caller address will be the same as the identity that signed the transaction to begin with. It would only be different if the Dapp tried to put in a callee address that it was not using to sign the transaction. I am also curious to understand the use case of needing an ethereum certificate over using the fabric one? What are the benefits gained?

conanoc (Fri, 30 Aug 2019 04:16:42 GMT):
@swetha "If we say ethereum identity needs to be connected to a fabric identity" I want to argue the opposite. I think fabric need not worry about ethereum identity. Because fabric need not worry about the internal ID system of the apps running on fabric. Ethereum is an app running on fabric. But currently, evmcc is touching the internal account of the app named "ethereum". I'd like to clarify this confusion. An ethereum node which serves evm-JSON-RPC can have two roles. One is serving the user running the node. The user is running a Dapp and a node on the his computer. He is the single user of the computer. The node has accounts generated by the user and the Dapp will use that accounts. The second role is serving multiple users as a proxy. The users are running Dapp on their own computers but are not running ethereum nodes. They use a proxy node which supports JSON-RPC. In this case, the users have their own accounts and they send transactions signed with their own certificate to the proxy. I've talked about this second case and you seem to considering only the first case. I think the second case is more common when we consider the ethereum nodes for the enterprise.

guoger (Fri, 30 Aug 2019 06:41:02 GMT):
Not sure i fully understand the question here but here's my response: > I think fabric need not worry about ethereum identity. Ultimately a tx needs to be signed by a signer, which needs to be 1-1 mapped to an account addr within Fabric, so the evm will know who's calling the contract. In another word, as long as evm itself doesn't manage an address space and does not do authentication, Fabric is going to be "worrying about ethereum" identity. as for submitting a signed tx via proxy or having a light node doing that for you, is orthogonal to this problem.

guoger (Fri, 30 Aug 2019 06:41:02 GMT):
@conanoc Not sure i fully understand the question here but here's my response: > I think fabric need not worry about ethereum identity. Ultimately a tx needs to be signed by a signer, which needs to be 1-1 mapped to an account addr within Fabric, so the evm will know who's calling the contract. In another word, as long as evm itself doesn't manage an address space and does not do authentication, Fabric is going to be "worrying about ethereum" identity. as for submitting a signed tx via proxy or having a light node doing that for you, is orthogonal to this problem.

conanoc (Fri, 30 Aug 2019 09:55:09 GMT):
@guoger Yeah. I was actually talking about signed tx. I agree that generating 1-1 mapped account for handling unsigned tx or doing some command line jobs can be a convenient way. What I wanted to say was fabric identity can be and should be independent to the ethereum identity.

guoger (Fri, 30 Aug 2019 09:58:16 GMT):
@conanoc are you suggesting that we double sign the tx - `F(E(m))`, where F is for fabric and E for ethereum?

conanoc (Fri, 30 Aug 2019 09:58:54 GMT):
Sure.

conanoc (Fri, 30 Aug 2019 10:01:28 GMT):
E(m) is necessary because it will be done offline usually and F(m') will be done by fabric's existing logic.

conanoc (Fri, 30 Aug 2019 10:03:35 GMT):
It may be confusing what tx mean here. I mean the fabric tx not the ethereum tx.

guoger (Fri, 30 Aug 2019 10:10:43 GMT):
ok i see. My confusion was actually around `fabric need not worry about ethereum identity`, because technically it does - it needs to get addr from pubkey.

guoger (Fri, 30 Aug 2019 10:11:47 GMT):
so it's not completely agnostic to ethereum identity in the sense that if ethereum changes the way it encodes addr, then evmcc is broken

conanoc (Fri, 30 Aug 2019 10:12:31 GMT):
Right.

guoger (Fri, 30 Aug 2019 10:12:53 GMT):
but anyway, i agree that we should be more compatible with wallets, and i don't think this require drastic change to out implementation

guoger (Fri, 30 Aug 2019 10:12:53 GMT):
but anyway, i agree that we should be more friendly with wallets, and i don't think this require drastic change to out implementation

guoger (Fri, 30 Aug 2019 10:12:53 GMT):
but anyway, i agree that we should be more friendly to wallets, and i don't think this require drastic change to out implementation

guoger (Fri, 30 Aug 2019 10:13:26 GMT):
let's see what others think when they wake up @swetha @MHBauer

conanoc (Fri, 30 Aug 2019 10:17:23 GMT):
I was confused that fab3 was already handling signed tx via eth_sendTrasaction RPC. I didn't know signed tx only sent via eth_sendRawTransaction RPC.

conanoc (Fri, 30 Aug 2019 10:18:47 GMT):
So I thought evmcc was replacing the caller address of the signed ethereum tx.

conanoc (Fri, 30 Aug 2019 10:22:33 GMT):
I think every thing will be clear when we implement eth_sendRawTransaction RPC. :smile:

swetha (Fri, 30 Aug 2019 16:44:59 GMT):
So in this scenario E(M) where E is ethereum is purely meant for encryption purposes. If this is the purpose then doing F(E(m)) is not a problem. My concern here is that Fab3 if it is doing F(x), where x is any transaction, is that it should not be used as a proxy that multiple users can use. Because from a fabric transaction standpoint only one user is submitting those transactions. I know Jay and I have talked about F(E(m)) as a way to introduce wallet support sooner than later. However, even if we don't care about the E(m) algorithm or identity, we should care that F(x) is done per user, not a group. If we break this, it opens the door for pseudo anonymous transactions which I feel like is a departure from Fabric. To be able to make fab3 a proxy that does no signing and simply acts as a way to send transactions, then I think the identity used needs to be one recognized by the system. This option requires that 1. either we support ethereum signing algorithm or 2. waiting on signing transactions through the go sdk. Though as I think about it we could support 2 now and leave it up to the user to figure out how to sign the transaction. If we support F(E(m)) I think we are then making Fab3 1-1 to a user. If we try to support using Fabric ways of submitting signed transactions we would be able to make fab3 more lightweight and simply a proxy.

swetha (Fri, 30 Aug 2019 16:45:10 GMT):
@conanoc , @guoger

conanoc (Sat, 31 Aug 2019 01:54:07 GMT):
@swetha Isn't F(x) done on the peer not on Fab3? Fab3 could have no function of signing. E(m) will be done on the ethereum Dapps, e,g, Wallets and sent to Fab3 via eth_sendRawTrasaction. Fab3 only checks the validity of the signature and bypasses the transaction to evmcc. F(x) will be done on the endorsing peers as usual. In this scenario, E(m) is not done when Fab3 is serving eth_sendTransaction because Fab3 is creating ethereum tx itself. I think it's not a problem because the ethereum tx is created by Fab3 itself, which means Fab3 don't have to verify the tx.

swetha (Sat, 31 Aug 2019 02:04:10 GMT):
F(x) validation is done on the peer side, but the actual signing currently is done on Fab3. So to submit anything it needs to be signed by an identity recognized by Fabric. Say we allow an ethereum cert to sign a transaction and send the raw transaction. That signed ethereum tx must be signed by with a fabric cert. Whether this is done through fab3 or outside, it doesn't matter. This is where you need to have a fabric identity.

swetha (Sat, 31 Aug 2019 02:06:01 GMT):
So what the role of Fab3 is in that end to end can change based on how the fabric signing is done

swetha (Sat, 31 Aug 2019 02:06:19 GMT):
@conanoc

conanoc (Mon, 02 Sep 2019 02:45:06 GMT):
I got what you mean. Thank you for your explanation. @swetha @guoger

silasdavis (Mon, 02 Sep 2019 12:14:27 GMT):
@swetha I have found a bit of time for us to finally take a look at integrating the fab3 web3 code into Burrow. Last time we spoke it was with regards to an intern which we didn't get but I remember you saying you had the go ahead in principle to spin https://github.com/hyperledger/fabric-chaincode-evm/tree/master/fab3 out into it sown repo? Is that still the case, not sure what kind of overhead that represents for you. Provided the import tree from the fab3 sub-package is fairly clean it is not a huge deal for us to start integrating by depending on fabric-chaincode-evm. Longer term if it makes it into Burrow master it would be preferable for it to be its own thing.

silasdavis (Mon, 02 Sep 2019 12:14:27 GMT):
@swetha I have found a bit of time for us to finally take a look at integrating the fab3 web3 code into Burrow. Last time we spoke it was with regards to an intern which we didn't get but I remember you saying you had the go ahead in principle to spin https://github.com/hyperledger/fabric-chaincode-evm/tree/master/fab3 out into it sown repo? Is that still the case? I'm not sure what kind of overhead that represents for you. Provided the import tree from the fab3 sub-package is fairly clean it is not a huge deal for us to start integrating by depending on fabric-chaincode-evm. Longer term if it makes it into Burrow master it would be preferable for it to be its own thing.

silasdavis (Mon, 02 Sep 2019 12:15:13 GMT):
Also reading above I think there will be some coordination needed if/when we add wallet support - assuming this involves `sendRawTransaction`.

silasdavis (Mon, 02 Sep 2019 12:15:53 GMT):
One piece we could definitely collaborate on is writing a Apache 2 golang RLP codec to pull out the eth transaction data

swetha (Tue, 03 Sep 2019 16:52:50 GMT):
@silasdavis I have to check if we still have the go ahead to move fab3 out. A few things that have changed from then to know, is that fabric and its sub components have been slowly moving from gerrit to github repositories. This involves changes in our CI/CD. I am thinking if I get the go ahead again, it would be best to coordinate with the move to github for the fabric-chaincode-evm. In regards to fab3 imports. They should be fairly clean. We are also trying to separate out the evmcc and fab3 code in the repository to make the evmcc easier to install as well as give us more flexibility with out dependencies between evmcc and fab3. Here is a wip branch of that code: https://github.com/swetharepakula/fabric-chaincode-evm/tree/split-evmcc-fab3.

MHBauer (Tue, 03 Sep 2019 20:32:54 GMT):
why did we think https://jira.hyperledger.org/browse/FAB-13768 was a problem? I can recall we kind of all independently think so, but the 'why' doesn't come to me anymore...

swetha (Wed, 04 Sep 2019 00:34:53 GMT):
@MHBauer The user address creation is not a problem in its current form. The issue was originally created to move towards being more similar to how ethereum generates address. As in directly getting the sum from the user's public key. The issue will not have much a change from a user perspective other than their user address being different

MHBauer (Wed, 04 Sep 2019 00:41:59 GMT):
well let's get it in the issue.

swetha (Wed, 04 Sep 2019 04:26:24 GMT):
There should be a comment from earlier today saying something similar

MHBauer (Wed, 04 Sep 2019 05:24:23 GMT):
SUPER

madiazp (Thu, 05 Sep 2019 06:24:34 GMT):
Hi, from where does the evmcc import the burrow package? They're not in the fabric-cli container's gopath, nor the peer's, and even when I remove the burrow files from the gopath of my local machine the chaincode is still installed and invokated with no problems.

madiazp (Thu, 05 Sep 2019 06:26:58 GMT):
I want to modify something on the evm/vm.go of the burrow package, but I'm not sure what path is the one that evmcc is using.

guoger (Thu, 05 Sep 2019 06:36:06 GMT):
IINM, it's in `vendor` dir

madiazp (Thu, 05 Sep 2019 06:38:35 GMT):
oh I see... Thanks!

Shezay (Thu, 05 Sep 2019 06:43:48 GMT):
Hi,I've been having an issue with fab3 for a few days now. I'm trying the getLogs call like in Fab3 Instructions: https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Fab3_Instructions.md#eth_getlogs however, I'm getting this message: {"jsonrpc":"2.0","error":{"code":-32000,"message":"rpc: can't find method \"eth.GetLogs\"","data":null},"id":1}`` I don't know what I'm doing wrong, because it used to work before. Any help is appreciated, thanks

swetha (Thu, 05 Sep 2019 13:58:43 GMT):
@Shezay what is the request you are sending?

Shezay (Fri, 06 Sep 2019 05:56:46 GMT):
@swetha I'm sending the request from the example curl http://127.0.0.1:5000 -X POST -H "Content-Type:application/json" -d '{ "jsonrpc":"2.0", "method": "eth_getLogs", "id":1, "params":[ {"fromBlock":"earliest", "address":"0x...", "topics":[]}] }' with a valid address of a smart contract I've deployed on the network and empty topics. But get the "can't find method getLogs" message.

swetha (Fri, 06 Sep 2019 06:09:02 GMT):
@Shezay what version of the code are you using?

swetha (Fri, 06 Sep 2019 06:11:40 GMT):
That error means that getLogs was not implemented. We introduced that api in our second release. So v0.2, v0.3 and master should not be having that problem

swetha (Fri, 06 Sep 2019 06:11:55 GMT):
If you are switching between versions, also check to make sure to rebuild fab3

swetha (Fri, 06 Sep 2019 06:11:55 GMT):
If you are switching between versions, also check to make sure you are rebuilding fab3

Shezay (Fri, 06 Sep 2019 06:29:23 GMT):
@swetha I thought it might have been that, so tried with the master and v0.2, and it didn't work with either. I rebuilt it, even installed evmcc again just in case. So at this point I thought it might have been something with a configuration file that is wrong, but idk if there's anything that may cause that problem? I did use fab3 to deploy some contracts and it worked, so idk why it wouldn't with that. I'll rebuild it again using the master branch just in case, and see if it works though

Shezay (Fri, 06 Sep 2019 06:52:06 GMT):
@swetha So I just removed the previous fabric-chaincode-evm directory, got the master branch, did the make fab3 command, restarted my cli container, installed the evm chaincode as evmcc2 set the Fab3 variables, started it, and sent the request and it still says it cannot find the getLogs method. I'm sorry if this is not getting anywhere haha but I'm a bit lost. I'm thinking of starting a brand new network on another machine and test it there. Just in case there is something wrong with this network or something

Shezay (Fri, 06 Sep 2019 11:11:54 GMT):
@swetha just tried it on another machine with a previous configuration, and it worked. So there must be something wrong with some of my changes

swetha (Fri, 06 Sep 2019 15:32:47 GMT):
@Shezay where/what are the changes you are making? Are you touching the codec file? Changes to the config file will not affect how fab3 works. That error is coming purely from the library we use to process the requests

MHBauer (Fri, 06 Sep 2019 15:42:18 GMT):
The issue must exist in a Fab3 change.

Shezay (Sat, 07 Sep 2019 17:31:42 GMT):
The reason why I don't believe the issue is in Fab3 itself is because I tried rebuilding it using version 0.2 and it kept giving me that issue. And on another machine, using 0.2 it didn't? I mean, I don't know I could be way wrong haha And no, @swetha I haven't touched any fab3 files. I was mostly speaking about maybe something being spelled wrong or wrong paths or something like that.

swetha (Sat, 07 Sep 2019 18:58:01 GMT):
@Shezay So the error is coming because the gorilla rpc library we use can't find a method eth.GetLogs, which should be corresponding to https://github.com/hyperledger/fabric-chaincode-evm/blob/release-0.2/fab3/ethservice.go#L388. Gorilla figures out what to look for from this file: https://github.com/hyperledger/fabric-chaincode-evm/blob/release-0.2/fab3/codec.go#L38-L51. Basically it takes eth_getLogs and turns it into eth.GetLogs. The error happens at the fab3 level. The request can't be processed, so it is returning the error, but it has not passed on the request to the fabric network yet. If there are not spelling errors and changes to those files, I am not sure why that error is happening. My only guess is that it could be because the args you are passing in does not match what getLogs is expecting. But if you are seeing on a clean clone of the repo and compiling your request is working, that tells me it has be linked to the changes you have.

Shezay (Sun, 08 Sep 2019 15:39:46 GMT):
@swetha ohh i see Thought as much, thank you so much for taking your time answering this. I'll look more into, see if I can find what was off

klenik (Fri, 13 Sep 2019 18:10:24 GMT):
@swetha Do you by any chance have a timeline for this update? https://github.com/swetharepakula/fabric-chaincode-evm/tree/split-evmcc-fab3 A self-contained evmcc vendor dir would be a huge help :)

swetha (Fri, 13 Sep 2019 18:17:42 GMT):
@klenik some of your struggles were part of the motivation of doing the split. :grinning: Code wise I think the work is almost ready, it needs a little rebasing with some of the new patches. The difficult thing is going to be the reviews as the change touches almost every file. Most are renames, but we still want to be careful. So I see the review process taking a while. So in regards to a concrete timeline, I don't have one. We do want that in our next release, but I am not sure when that will be

MHBauer (Fri, 13 Sep 2019 18:32:36 GMT):
lol.

MHBauer (Fri, 13 Sep 2019 18:33:04 GMT):
pretty sure I already reviewed it.

swetha (Fri, 13 Sep 2019 19:13:34 GMT):
yes, you started reviewing and had suggestions as well as more things you wanted to look at it

klenik (Fri, 13 Sep 2019 19:13:47 GMT):
@swetha glad I could contribute to your pile of todos 😁 then I think I'll do some unofficial testing on your branch

swetha (Fri, 13 Sep 2019 19:14:57 GMT):
Yes, @MHBauer we did go through some initial reviews, but iirc they weren't complete and more exploratory to make sure I wasn't missing anything obvious. Also I am not sure the suggestions that came out of that have been completely incorporated into the branch

swetha (Fri, 13 Sep 2019 19:14:57 GMT):
Yes, @MHBauer we did go through some initial reviews, but iirc they weren't complete and were more exploratory to make sure I wasn't missing anything obvious. Also I am not sure the suggestions that came out of that have been completely incorporated into the branch

swetha (Fri, 13 Sep 2019 19:15:42 GMT):
@klenik functionality wise that branch should be the same as testing on master of fabric-chaincode-evm :)

swetha (Fri, 13 Sep 2019 19:16:22 GMT):
might be a little different in terms of what is vendored as now their is more flexibility

swetha (Fri, 13 Sep 2019 19:16:22 GMT):
might be a little different in terms of what is vendored as now there is more flexibility

klenik (Fri, 13 Sep 2019 19:16:39 GMT):
@swetha awesome! Hopefully I won't break it with my own added mods 😅

swetha (Fri, 13 Sep 2019 19:17:53 GMT):
haha, look forward to hearing your feedback!

klenik (Fri, 13 Sep 2019 19:20:55 GMT):
Any reason for also vendoring the fabric modules? They should be available inside the peer image, shouldn't they? (I'm a golang vendor novice, so forgive me if it's a stupid question)

klenik (Fri, 13 Sep 2019 19:29:37 GMT):
(at least the chaincodes I've seen so far haven't vendored them, and can still access the stub and other modules)

swetha (Fri, 13 Sep 2019 19:30:32 GMT):
@klenik Mostly ease of developing and testing outside of a fabric peer image

klenik (Fri, 13 Sep 2019 19:32:27 GMT):
Shouldn't cloning the fabric source into gopath would achieve the same? And it'd also decrease the evmcc vendor folder size (and wouldn't bind it to a specific fabric version)

swetha (Fri, 13 Sep 2019 19:45:32 GMT):
yes what you said makes sense in efforts to reduce the vendor folder size

swetha (Fri, 13 Sep 2019 19:45:57 GMT):
though I think we open the door to more development issues depending on fabric in someone's gopath

swetha (Fri, 13 Sep 2019 19:47:12 GMT):
Versioning can become a problem, especially for someone who is also developing on fabric. Though fabric in terms of user functionality might not have breaking changes, they could have changes in the individual functions internally that we use or depend on.

swetha (Fri, 13 Sep 2019 19:48:29 GMT):
We probably get hit on this in our testing more than our chaincode as we depend on a lot of the testing helpers and utils in the fabric repo

swetha (Fri, 13 Sep 2019 19:48:36 GMT):
and those change version to version

swetha (Fri, 13 Sep 2019 19:52:13 GMT):
What you brought up though is interesting and I haven't really given it much thought before. Our current vendoring was a product of just how we/I were/was used to development for a go project, but I think it would be valuable to explore removing fabric from the evmcc vendor

klenik (Fri, 13 Sep 2019 19:52:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=4uv46S73EYXbhbkZ5) I haven't considered this aspect. In this case it makes perfect sense to vendor fabric modules :ok_hand:

klenik (Fri, 13 Sep 2019 19:53:42 GMT):
I don't know whether devDependency concept exists in go, but that would be a good solution for this

swetha (Fri, 13 Sep 2019 19:54:43 GMT):
The more I think about it, the verisioning I think is the biggest issue, because right now we don't depend on the version of fabric available in the peer. And most chaincodes to my knowledge don't depend on modules in fabric as much as we do, so I feel like there is also more possibility of errors in that way too. But I am not sure

swetha (Fri, 13 Sep 2019 20:00:25 GMT):
Dev dependencies is one thought. I don't think that is a built in concept and would be more about how a specific project is managed

swetha (Fri, 13 Sep 2019 20:01:32 GMT):
I would love to hear what you learn if you experiment with removing fabric from the vendor directory. Definitely would be open to that as long as we figured out a way to keep development easy enough

swetha (Fri, 13 Sep 2019 20:01:47 GMT):
@MHBauer & @guoger may have more thoughts on the subject as well

MHBauer (Sat, 14 Sep 2019 04:40:49 GMT):
modules and stop vendoring

MHBauer (Sat, 14 Sep 2019 04:41:00 GMT):
ut I dunno how any of it works in real life

klenik (Sun, 15 Sep 2019 09:09:59 GMT):
How about using a hierarchical vendor structure? Something like this: ``` repo-root/ ├── modules/ │ ├── evmcc/ │ │ └── vendor/ │ │ └── runtime deps without fabric │ └── fab3/ │ └── vendor/ │ └── runtime deps └── vendor/ └── dev&test deps ``` This way you still bind the fabric modules to your repo for dev&test, and evmcc is not packaged with fabric. Haven't tried such a structure yet, but _in theory_ it sounds doable (and maintainable)

charyorde (Sun, 15 Sep 2019 14:24:35 GMT):
Has joined the channel.

MHBauer (Sun, 15 Sep 2019 15:17:10 GMT):
Does that even work? I'm not sure that would help.

MHBauer (Sun, 15 Sep 2019 15:17:43 GMT):
and its not really different from the three folders we have to move towards right now.

klenik (Sun, 15 Sep 2019 21:01:29 GMT):
From this: https://golang.org/cmd/go/#hdr-Vendor_Directories > Code below a directory named "vendor" is importable only by code in the directory tree rooted at the parent of "vendor", and only using an import path that omits the prefix up to and including the vendor element. So the evmcc code would see the union of packages in `reporoot/vendor` and `evmcc/vendor`, but the different types of deps are still kept separated (if I understood the above rule correctly, kind of like node_modules for Node.js). (I haven't tried the modules feature yet, seems cleaner than vendoring, but a multi-module repo is still discouraged in the go wiki.) Anyway, these are just some ideas, you probably know the reqs and constraints of your repo better

klenik (Mon, 16 Sep 2019 12:38:44 GMT):
@MHBauer @swetha I've run into a strange behavior for a contract. An event marshalling error occurs after deploying a Solidity contract. I've gathered every related info in this gist: https://gist.github.com/aklenik/0f02e12a4a4c0461aedbd5249d3d8f0d So far this is the only contract that produced the error (tried other contracts with/without constructor arguments, those worked fine). Can you also reproduce this in the master branch? (I'm working with the fork of @swetha )

swetha (Mon, 16 Sep 2019 21:41:31 GMT):
@klenik which contract are you deploying?

klenik (Mon, 16 Sep 2019 21:43:16 GMT):
This: https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/payment/escrow (included the exact source in the gist above)

klenik (Mon, 16 Sep 2019 21:45:37 GMT):
(RefundEscrow.sol)

swetha (Mon, 16 Sep 2019 22:20:13 GMT):
so i don't get an error when i deploy the refund escrow contract and put my user address as the argument to the constructor!

swetha (Mon, 16 Sep 2019 22:20:13 GMT):
so i don't get an error when i deploy the refund escrow contract and put my user address as the argument to the constructor

swetha (Mon, 16 Sep 2019 22:35:09 GMT):
What are the actual transactions you are running that are producing the error?

swetha (Mon, 16 Sep 2019 22:36:22 GMT):
I see one log in the deployment and if I am reading the contracts correctly I believe that is what is expected?

klenik (Mon, 16 Sep 2019 22:37:34 GMT):
Haven't got that far, the deploy step returned the mentioned error for me. It couldn't marshal the chaincode event (which is the first 8 byte of the new contract address), complaining about invalid UTF8 string :/

klenik (Mon, 16 Sep 2019 22:38:09 GMT):
Did you compile the source, or deployed the bytecode directly from the gist?

klenik (Mon, 16 Sep 2019 22:39:57 GMT):
(the same line for event encoding works for other contracts... that's why I found it strange)

swetha (Mon, 16 Sep 2019 22:43:51 GMT):
Oh I just saw the piece at the bottom of the gist.

swetha (Mon, 16 Sep 2019 22:44:00 GMT):
I took the file and put it in remix and deployed it

swetha (Mon, 16 Sep 2019 22:45:18 GMT):
Is the bytcode in the file with an address added to the end already?

klenik (Mon, 16 Sep 2019 22:52:10 GMT):
The second bytecode contains the argument

klenik (Mon, 16 Sep 2019 22:52:46 GMT):
(the first is just the output of the compiler)

swetha (Mon, 16 Sep 2019 22:57:16 GMT):
Okay, cool. Just realized I was using remix with the inbuilt vm. Retrying now with the peer cli and the directions you gave

swetha (Mon, 16 Sep 2019 23:09:32 GMT):
@klenik So I keep running into a timeout issue, that is something I have not seen before. But the one time I have not got the timeout issue the contract deployed fine and I am able to query the beneficiary

klenik (Mon, 16 Sep 2019 23:10:57 GMT):
Yeah, on the client side it manifests as a timeout, because the peer raises a timeout, since it doesn't get a response from the CC. Which is halted because of a marshalling error. The CC container logs contain the actual issue

swetha (Mon, 16 Sep 2019 23:15:25 GMT):
Interesting, I don't see any logs in the CC container

swetha (Mon, 16 Sep 2019 23:15:39 GMT):
And in the peer logs it is as you said

swetha (Mon, 16 Sep 2019 23:16:25 GMT):
But this exercise does seem to indicate that the problem exists on master

klenik (Mon, 16 Sep 2019 23:17:02 GMT):
Ah, yeah, I changed the logging in the `main` function to: `logger.Errorf("Error starting EVM chaincode: %+v", err)` `%+v` will give you the detailed error

klenik (Mon, 16 Sep 2019 23:18:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=gjZegZTGaNLBCd2kr) Or maybe in the Burrow EVM. The contract address is returned from an EVM module. Although there is a slicing in evmcc before it's added to the events

swetha (Mon, 16 Sep 2019 23:22:01 GMT):
Would you be willing to convert the gist you made into a jira issue?

klenik (Mon, 16 Sep 2019 23:23:13 GMT):
Sure, I'll raise the issue tomorrow :thumbsup:

swetha (Mon, 16 Sep 2019 23:24:54 GMT):
thanks!

klenik (Tue, 17 Sep 2019 11:32:14 GMT):
@swetha https://jira.hyperledger.org/browse/FAB-16620

swetha (Tue, 17 Sep 2019 17:29:24 GMT):
thanks @klenik !

swetha (Tue, 17 Sep 2019 22:23:13 GMT):
@here Our monthly meeting for the Fabric Chaincode EVM is tomorrow at 8 AM PST Meeting Event: https://calendar.google.com/calendar/event?eid=NGdxaGpjYXNsYjRjZjVobG1vY3RobnFicnRfMjAxOTA5MThUMTUwMDAwWiBsaW51eGZvdW5kYXRpb24ub3JnX25mOXU2NGc5azlydmQ5Zjh2cDR2dXIyM2IwQGc&ctz=America/Los_Angeles

swetha (Tue, 17 Sep 2019 22:23:21 GMT):
Please feel free to add to agenda here: https://wiki.hyperledger.org/display/fabric/September+18th+2019

MHBauer (Wed, 18 Sep 2019 21:16:50 GMT):
@BrettLogan I think if there was going to be some help doing the cutover we'd be fine with it. I can move my open changes if we lose that.

BrettLogan (Wed, 18 Sep 2019 21:16:50 GMT):
Has joined the channel.

MHBauer (Wed, 18 Sep 2019 21:18:19 GMT):
I think we had some questions about the amount of people required to do a merge. go from 2 to 1.

swetha (Wed, 18 Sep 2019 22:52:12 GMT):
Yes, we were wondering what is the process to change the policy from 2 maintainers to a single non-author maintainer

swetha (Wed, 18 Sep 2019 22:52:51 GMT):
though that might be a question for the hyperledger staff who are doing the actual gerrit to github migration

MHBauer (Wed, 18 Sep 2019 23:28:24 GMT):
@swetha this is what it would look like in travis. https://github.com/MHBauer/fabric-chaincode-evm/pull/3/files

MHBauer (Wed, 18 Sep 2019 23:28:42 GMT):
could matrix the go and node versions if we wanted.

swetha (Wed, 18 Sep 2019 23:47:33 GMT):
To track our migration: https://wiki.hyperledger.org/display/fabric/Migration+to+Github

BrettLogan (Thu, 19 Sep 2019 00:00:50 GMT):
To move to the one +2 for merges, open a Jira with the proposal. Then make the Jira proposal public in the fabric-maintainers and fabric-evm with a few days of debate (specify a debate deadline). Then have your maintainers vote at the end of that period by commenting on the Jira. Assuming a majority of maintainers vote yes, it is trivial in GitHub to change to one +2, which Ry will do for the repo with proof of the Jira passing majority

BrettLogan (Thu, 19 Sep 2019 00:00:50 GMT):
To move to the one +2 for merges, open a Jira with the proposal. Then make the Jira proposal public in the fabric-maintainers and fabric-evm with a few days of debate (specify a debate deadline). Then have your maintainers vote at the end of that period by commenting on the Jira. Assuming a majority of votes, it is trivial in GitHub to change to one +2, which Ry will do for us with proof of the Jira passing majority

BrettLogan (Thu, 19 Sep 2019 00:00:50 GMT):
To move to the one +2 for merges, open a Jira with the proposal. Then make the Jira proposal public in the fabric-maintainers and fabric-evm with a few days of debate (specify a debate deadline). Then have your maintainers vote at the end of that period by commenting on the Jira. Assuming a majority of votes, it is trivial in GitHub to change to one +2, which Ry will do for the repo with proof of the Jira passing majority

BrettLogan (Thu, 19 Sep 2019 00:07:00 GMT):
@MHBauer @swetha There are two options for the migration in terms of CI, I can recreate your current Jenkins pipeline in Azure, and then once you have all of the changes merged that you want merged, I will have LF cut the mirror and you will take over from there (with the blessing of your maintainers). You then completely own your CI and you can edit and maintain it however you see fit (this is definitely the easier and faster option). The other option is you fork the repo, get an Azure Pipelines account yourself, tie your forked repo to it, and create a new pipeline that does what you want it to do. Then when you are happy with the state of this pipeline you built, you will take your Azure YAML, commit it to the hyperledger fabric-chaincode-evm repo in gerrit, and then we can flip the switch and switch to GitHub (this path is time dependent on you forming an Azure YAML file you are happy with).

BrettLogan (Thu, 19 Sep 2019 00:07:00 GMT):
@MHBauer @swetha There are two options for the migration in terms of CI, I can recreate your current Jenkins pipeline in Azure, and then once you have all of the changes merged that you want merged, I will have LF cut the mirror and you will take over from there. You then completely own your CI and you can edit and maintain it however you see fit (this is definitely the easier and faster option). The other option is you fork the repo, get an Azure Pipelines account yourself, tie your forked repo to it, and create a new pipeline that does what you want it to do. Then when you are happy with the state of this pipeline you built, you will take your Azure YAML, commit it to the hyperledger fabric-chaincode-evm repo in gerrit, and then we can flip the switch and switch to GitHub (this path is time dependent on you forming an Azure YAML file you are happy with).

MHBauer (Thu, 19 Sep 2019 00:07:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=SdADG8SBB2GE7pyEa) majority of voters or majority of maintainers? we've got like 6 maintainers listed, but only 2+1 really do anything

BrettLogan (Thu, 19 Sep 2019 00:08:34 GMT):
Modified it to say majority of maintainers

BrettLogan (Thu, 19 Sep 2019 00:10:56 GMT):
While I agree, only a few actually maintain it, this is the process we have followed in Fabric in the past for things like this. We had at one time also proposed going to one +2 in Fabric (never followed through with it), and this was what the maintainers and LF felt was the best way to put it in the public and make sure the change was valid

MHBauer (Thu, 19 Sep 2019 00:11:52 GMT):
yea, sounds good.

BrettLogan (Thu, 19 Sep 2019 00:11:54 GMT):
It's one of those things that really need a better process spelled out by the TSC and added to the charter.

MHBauer (Thu, 19 Sep 2019 00:12:05 GMT):
I'm fine with it. We'll have to maybe track down some pepole.

MHBauer (Thu, 19 Sep 2019 00:12:20 GMT):
I can write that up if it helps.

BrettLogan (Thu, 19 Sep 2019 00:12:23 GMT):
I can get Gari and Jay, I talk to both of them almost every day

MHBauer (Thu, 19 Sep 2019 00:12:26 GMT):
meeting is too early for me to go to

MHBauer (Thu, 19 Sep 2019 00:13:49 GMT):
I'd rather do the first option, let someone else try and figure it out.

swetha (Thu, 19 Sep 2019 00:13:52 GMT):
I think we will be able to get Gari, Jay, and Chris on board

MHBauer (Thu, 19 Sep 2019 00:13:58 GMT):
It's not a complicated build.

swetha (Thu, 19 Sep 2019 00:14:05 GMT):
so that itself if 5/6 ?

BrettLogan (Thu, 19 Sep 2019 00:14:06 GMT):
I'll be honest, if you could write the Jira for it, that would be a huge help, the amount of doc I am in the midst of writing for contribution guidelines is eating at my cycles

MHBauer (Thu, 19 Sep 2019 00:14:28 GMT):
for us specifically, or the process in general?

BrettLogan (Thu, 19 Sep 2019 00:14:40 GMT):
The process in general

BrettLogan (Thu, 19 Sep 2019 00:14:58 GMT):
Since we are moving Fabric next week, we need to make sure the doc is 100% updated now

BrettLogan (Thu, 19 Sep 2019 00:17:26 GMT):
If EVM wants to go with option #1, then the only thing the EVM maintainers need to do, is get in what you want with Gerrit, and vote on the change to one +2. Then if everyone is agreement they are ready to move, we can flip the switch. That whole process takes about 5 minutes (quite trivial)

BrettLogan (Thu, 19 Sep 2019 00:17:52 GMT):
I'll take care of setting up everything in Azure, and giving you a base pipeline

MHBauer (Thu, 19 Sep 2019 00:18:09 GMT):
alright, I think some of the smaller things we can merge. I'm personally fine with making new PRs on the other side.

swetha (Thu, 19 Sep 2019 00:18:26 GMT):
I am with Morgan, I think option 1 will be nice

swetha (Thu, 19 Sep 2019 00:18:47 GMT):
We can merge the smaller changes in and at the same time finish the jira proposal + debate

BrettLogan (Thu, 19 Sep 2019 00:19:15 GMT):
Also, you have 4 branches, do you want all 4 to run through CI. In Fabric's core repos we are only taking master and our LTS (release-1.4) branches

BrettLogan (Thu, 19 Sep 2019 00:20:01 GMT):
You can always add them later, but when I create the initial definition file I just want to make sure the branches you want included, all work

swetha (Thu, 19 Sep 2019 00:20:02 GMT):
We just need to track master

swetha (Thu, 19 Sep 2019 00:20:34 GMT):
we haven't had much need to add to the release branches after the fact so I don't think we need that setup right now

MHBauer (Thu, 19 Sep 2019 00:20:37 GMT):
yes, only one branch

BrettLogan (Thu, 19 Sep 2019 00:21:36 GMT):
Perfect, I will get this file done asap, (should be trivial, your current pipeline is quite simple). Then once you've all closed out the other loops we can go ahead with the migration

BrettLogan (Thu, 19 Sep 2019 00:21:40 GMT):
Thanks both of you!

MHBauer (Thu, 19 Sep 2019 00:21:46 GMT):
:+1:

swetha (Thu, 19 Sep 2019 00:22:30 GMT):
Thanks !

swetha (Thu, 19 Sep 2019 01:01:17 GMT):
@muralisr , @MHBauer , @guoger , @cbf , @mastersingh24 we need majority maintainer approval on this proposal to change the number of required reviews: https://jira.hyperledger.org/browse/FAB-16649

conanoc (Fri, 20 Sep 2019 09:24:20 GMT):
@swetha I opened a jira for eth_sendRawTransaction RPC. https://jira.hyperledger.org/browse/FAB-16667 and put the ticket number to the commit message of https://gerrit.hyperledger.org/r/c/fabric-chaincode-evm/+/33600

swetha (Fri, 20 Sep 2019 18:09:51 GMT):
@conanoc Thanks for making the issue

swetha (Fri, 20 Sep 2019 18:55:55 GMT):
@conanoc We are in the middle of trying to move from gerrit to github to host our repository. Would you be willing to resubmit your CR using github pull requests after the merge. I think your patches/feature will require some discussion before they can be merged in

swetha (Fri, 20 Sep 2019 19:16:37 GMT):
@BrettLogan & @rjones The proposal to change the review policy has already got majority votes and we are almost done clearing all the CRs in gerrit. I think we can aim for beginning of next week to make the switch? /cc @MHBauer @guoger

rjones (Fri, 20 Sep 2019 19:16:37 GMT):
Has joined the channel.

rjones (Fri, 20 Sep 2019 19:17:46 GMT):
@swetha sure

rjones (Fri, 20 Sep 2019 19:18:25 GMT):
There are only a few open CRs: https://gerrit.hyperledger.org/r/q/project:fabric-chaincode-evm+status:open

MHBauer (Fri, 20 Sep 2019 19:20:13 GMT):
I'm abandoning mine

rjones (Fri, 20 Sep 2019 19:20:58 GMT):
I can break the CI mirror at any time, but I don't have anything to do with the CI part, so we would need to work with @BrettLogan and @sykesm

rjones (Fri, 20 Sep 2019 19:20:58 GMT):
I can break the Gerrit mirror at any time, but I don't have anything to do with the CI part, so we would need to work with @BrettLogan and @sykesm

sykesm (Fri, 20 Sep 2019 19:20:59 GMT):
Has joined the channel.

MHBauer (Fri, 20 Sep 2019 19:22:25 GMT):
ah, okay. I've got a travis config we could use until the jenkins is converted to azure, but I guess that means we wait.

rjones (Fri, 20 Sep 2019 19:23:01 GMT):
Sorry, I said CI when I meant Gerrit.

swetha (Fri, 20 Sep 2019 19:30:16 GMT):
There are only 2 CRs left, that I want to confirm with the submitter before we abandon them and then I am okay making the switch

rjones (Fri, 20 Sep 2019 19:41:54 GMT):
To prep for this, I've added you all (in CODEOWNERS) in the Maintainer role for https://github.com/hyperledger/fabric-chaincode-evm

rjones (Fri, 20 Sep 2019 19:45:05 GMT):
please wait to merge this: https://gerrit.hyperledger.org/r/c/fabric-chaincode-evm/+/33643

rjones (Fri, 20 Sep 2019 19:47:02 GMT):
until all of the other CRs are either merged or abandoned.

MHBauer (Fri, 20 Sep 2019 19:51:01 GMT):
cool

MHBauer (Mon, 23 Sep 2019 18:17:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=cGDNjDZTNcthjuRmo) @conanoc Have you seen this? I'm confused by the PR stack now as it looks like there's two different top commits, and three total.

rjones (Mon, 23 Sep 2019 19:35:41 GMT):
@MHBauer should we just mark the repo read-only and move on?

rjones (Mon, 23 Sep 2019 19:35:52 GMT):
I'm OOF today so Tuesday works for me

MHBauer (Mon, 23 Sep 2019 19:36:59 GMT):
That's my opinion, but I think we need to get the CI working. I'm in no rush.

swetha (Mon, 23 Sep 2019 20:06:29 GMT):
I think Tuesday should work. Still waiting on confirmation from @conanoc about moving his CR stack to github.

MHBauer (Mon, 23 Sep 2019 20:18:19 GMT):
OOF, out of florida?

MHBauer (Mon, 23 Sep 2019 20:23:31 GMT):
ah, a search says something something you used to work for microsoft or with someone from microsoft who said taht.

MHBauer (Mon, 23 Sep 2019 20:57:25 GMT):
At this point, I'm confident we can cut over and use travis or github actions if necessary.

swetha (Mon, 23 Sep 2019 21:49:05 GMT):
I would rather not keep switching through ci/cds. I am okay moving over to github without ci being ready and we just waiting on ci to be ready before merging any code changes

MHBauer (Mon, 23 Sep 2019 21:50:23 GMT):
ya, sure. I'm not sure what azure pipes gets us the others don't.

MHBauer (Mon, 23 Sep 2019 21:51:18 GMT):
I'm not about to let it have the permissions it wants on my account to find otu.

swetha (Mon, 23 Sep 2019 21:57:02 GMT):
Our ci pipeline is fairly small & simple, so my guess is that all of the options out there will work for our needs. However if fabric is moving to azure pipelines, then I think we should use that as well. We are a sub component, so I think we should go with that approach for consistency and ease for people who are contributing across the different fabric repos

MHBauer (Mon, 23 Sep 2019 22:03:07 GMT):
that is not a good arument.

MHBauer (Mon, 23 Sep 2019 22:03:26 GMT):
but sure. eagerly await the transition.

swetha (Mon, 23 Sep 2019 22:22:01 GMT):
Is there something that travis or github actions gets us that azure pipelines dont?

MHBauer (Mon, 23 Sep 2019 22:24:47 GMT):
no idea, not going to let azure have the permissions it's asking for. The travis one is at least very simple. Five or so lines.

MHBauer (Mon, 23 Sep 2019 22:25:04 GMT):
actions is a huge mess.

MHBauer (Mon, 23 Sep 2019 22:25:55 GMT):
other hyperledger projects are using other things.

MHBauer (Mon, 23 Sep 2019 22:26:09 GMT):
we're not even using the same jenkins setup as fabric core, so the continuity there is nil already.

swetha (Mon, 23 Sep 2019 22:30:29 GMT):
To what I have read of the CI/CD task force it looks like the other options being used were looked at. Not have the same jenkins setup did cause issues for us when we needed help in the past

swetha (Mon, 23 Sep 2019 22:31:58 GMT):
Here we will have more control so maybe it won't be a problem

MHBauer (Mon, 23 Sep 2019 22:32:14 GMT):
I would say that, yes. The other team required to do anything.

MHBauer (Mon, 23 Sep 2019 22:32:21 GMT):
Was the problem.

MHBauer (Mon, 23 Sep 2019 22:32:31 GMT):
Though why did we choose to have a different jenkins setup?

swetha (Mon, 23 Sep 2019 22:32:44 GMT):
We didn't, they were trying to move all projects to jenkins pipelines

swetha (Mon, 23 Sep 2019 22:33:02 GMT):
I think other than fabric core, the sub components were moved to the pipelines

MHBauer (Mon, 23 Sep 2019 22:33:18 GMT):
lol, that never happened in the end, did it?

swetha (Mon, 23 Sep 2019 22:33:41 GMT):
I think by then the task force started about looking at ci/cd and handling it differently

swetha (Mon, 23 Sep 2019 22:33:41 GMT):
I think by then the task force started looking at ci/cd and handling it differently

MHBauer (Mon, 23 Sep 2019 22:34:43 GMT):
ah,

MHBauer (Mon, 23 Sep 2019 22:34:49 GMT):
task force sounds so awesome

MHBauer (Mon, 23 Sep 2019 22:34:55 GMT):
can we form a task force?

swetha (Mon, 23 Sep 2019 22:35:25 GMT):
This is the ci/cd task force page on the wiki https://wiki.hyperledger.org/pages/viewpage.action?pageId=6428757

MHBauer (Mon, 23 Sep 2019 22:35:44 GMT):
ya, I've seen it.

MHBauer (Mon, 23 Sep 2019 22:40:53 GMT):
not a lot of info there.

swetha (Mon, 23 Sep 2019 22:42:32 GMT):
https://wiki.hyperledger.org/pages/viewpage.action?pageId=16322259 has some of the notes of why they looked at azure I think

rjones (Tue, 24 Sep 2019 01:04:39 GMT):
Fabric itself is going to AZP. Some projects want to use Github Actions, which are basically rebranded AZP

BrettLogan (Tue, 24 Sep 2019 03:05:42 GMT):
https://gerrit.hyperledger.org/r/c/fabric-chaincode-evm/+/33678

BrettLogan (Tue, 24 Sep 2019 03:07:59 GMT):
@swetha @MHBauer The initial file replicating what exists today in Jenkins.

BrettLogan (Tue, 24 Sep 2019 03:13:07 GMT):
https://dev.azure.com/btl5037/Fabric-Chaincode-EVM/_build/results?buildId=188&view=logs

BrettLogan (Tue, 24 Sep 2019 03:13:07 GMT):
https://dev.azure.com/btl5037/Fabric-Chaincode-EVM/_build/results?buildId=188&view=results

BrettLogan (Tue, 24 Sep 2019 03:13:24 GMT):
Here is a link to a successful run of it, if you want to verify or take a look at the logs

BrettLogan (Tue, 24 Sep 2019 03:13:24 GMT):
Here is a link to a successful run of it, if you want to take a look at the logs

rjones (Tue, 24 Sep 2019 03:53:06 GMT):
@BrettLogan @swetha @MHBauer if you want to enable AZP I can invite you to the Hyperledger AZP org

rjones (Tue, 24 Sep 2019 03:53:29 GMT):
swetha

rjones (Tue, 24 Sep 2019 03:53:34 GMT):
swetha

rjones (Tue, 24 Sep 2019 03:53:40 GMT):
MHBauer

swetha (Tue, 24 Sep 2019 16:21:57 GMT):
@BrettLogan Thanks. The pipeline looks great!

MHBauer (Tue, 24 Sep 2019 16:26:54 GMT):
@rjones so everything but yours and azp is merged.

MHBauer (Tue, 24 Sep 2019 16:27:04 GMT):
I think we merge the pipeline and then yours and then someone hits a switch?

swetha (Tue, 24 Sep 2019 16:31:23 GMT):
@MHBauer merge the azo

swetha (Tue, 24 Sep 2019 16:31:23 GMT):
@MHBauer merge the azp

MHBauer (Tue, 24 Sep 2019 16:31:32 GMT):
I thought I did?

MHBauer (Tue, 24 Sep 2019 16:31:38 GMT):
I did "submit"

MHBauer (Tue, 24 Sep 2019 16:31:41 GMT):
is that not merge?

swetha (Tue, 24 Sep 2019 16:31:44 GMT):
i see the update now

swetha (Tue, 24 Sep 2019 16:32:14 GMT):
Merged Ry's change

swetha (Tue, 24 Sep 2019 16:32:19 GMT):
I think we are ready!

MHBauer (Tue, 24 Sep 2019 16:32:35 GMT):
Ry seems ready.

rjones (Tue, 24 Sep 2019 16:33:56 GMT):
I'm ready

MHBauer (Tue, 24 Sep 2019 16:34:19 GMT):
good, we're all ready then.

rjones (Tue, 24 Sep 2019 16:38:26 GMT):
The last step would be for someone ( @BrettLogan ? ) to remove everything from the ci-managament repo

MHBauer (Tue, 24 Sep 2019 16:41:07 GMT):
is that the part that read-only's gerrit?

MHBauer (Tue, 24 Sep 2019 16:41:18 GMT):
or the part that runs the jenkins pipeline?

rjones (Tue, 24 Sep 2019 16:56:47 GMT):
the part that runs the Jenkins pipeline. Since you aren't using it/

MHBauer (Tue, 24 Sep 2019 16:56:55 GMT):
yay

rjones (Tue, 24 Sep 2019 16:58:14 GMT):
if you go here: https://dev.azure.com/Hyperledger/ and log in with your GitHub SSO credentials, you should show up and be able to see how things are going

rjones (Tue, 24 Sep 2019 17:01:01 GMT):
https://gerrit.hyperledger.org/r/c/ci-management/+/33701 @BrettLogan @sykesm

MHBauer (Tue, 24 Sep 2019 17:04:52 GMT):
swetha already getting on it.

MHBauer (Tue, 24 Sep 2019 17:13:00 GMT):
aww, you closed it.

rjones (Tue, 24 Sep 2019 17:13:08 GMT):
?

rjones (Tue, 24 Sep 2019 17:13:37 GMT):
Oh I see: https://github.com/hyperledger/fabric-chaincode-evm/pull/8

MHBauer (Tue, 24 Sep 2019 17:13:55 GMT):
Is the pipeline results going to show up as a check in GH?

rjones (Tue, 24 Sep 2019 17:14:01 GMT):
yes

rjones (Tue, 24 Sep 2019 17:14:15 GMT):
I just enabled that. I couldn't do that until it had run once

MHBauer (Tue, 24 Sep 2019 17:14:19 GMT):
and can we get a "build success" badge or something? not that we'll ever merge anything that fails I suppose.

MHBauer (Tue, 24 Sep 2019 17:14:22 GMT):
NEAT!

rjones (Tue, 24 Sep 2019 17:15:03 GMT):
this is why I have like 500 abandoned PRs called "Create DCO"; I can't enable the DCO bot until it fails once.

MHBauer (Tue, 24 Sep 2019 17:16:47 GMT):
lol

rjones (Tue, 24 Sep 2019 17:26:54 GMT):
I have strong feelings about GitHub :)

rjones (Tue, 24 Sep 2019 17:27:06 GMT):
OK - I think you guys are on your way, right? nothing more needed?

rjones (Tue, 24 Sep 2019 17:27:27 GMT):
You might edit the CODEOWNERS file to point to the actual people you want doing reviews

BrettLogan (Tue, 24 Sep 2019 17:28:29 GMT):
Ry, did you install LGTM in the Hyperledger Org?

MHBauer (Tue, 24 Sep 2019 17:28:33 GMT):
how so?

BrettLogan (Tue, 24 Sep 2019 17:28:47 GMT):
Or did Microsoft do it once they bought LGTM last week

swetha (Tue, 24 Sep 2019 17:29:50 GMT):
oh that's a good idea! I didn't think about that

swetha (Tue, 24 Sep 2019 17:30:15 GMT):
@rjones & @BrettLogan Is there a way to get github & jira integrations?

BrettLogan (Tue, 24 Sep 2019 17:31:03 GMT):
Not at the moment. The integration is only supported with the SaaS version of Jira, not the onprem

swetha (Tue, 24 Sep 2019 17:31:58 GMT):
ahh okay

swetha (Tue, 24 Sep 2019 17:32:12 GMT):
Thanks everyone for their help!

rjones (Tue, 24 Sep 2019 17:32:59 GMT):
@BrettLogan I installed LGTM last week

rjones (Tue, 24 Sep 2019 17:33:21 GMT):
It should only be in an advisory role, I didn't make it required anywhere

MHBauer (Tue, 24 Sep 2019 17:35:09 GMT):
and so what does that do?

BrettLogan (Tue, 24 Sep 2019 17:38:22 GMT):
It's unfortunately misidentifying projects. It thinks Fabric-CA is a python project

swetha (Tue, 24 Sep 2019 17:44:25 GMT):
It thinks fabric-evm is javascript

MHBauer (Tue, 24 Sep 2019 17:44:34 GMT):
is that based on looking at only the change tho?

swetha (Tue, 24 Sep 2019 17:44:57 GMT):
nope it says that on the readme pr

MHBauer (Tue, 24 Sep 2019 17:44:57 GMT):
Would it see a go project if we made a go change?

rjones (Tue, 24 Sep 2019 18:35:28 GMT):
I don't have super strong feelings about the plugin. Gari asked for some other plugin as well

rjones (Tue, 24 Sep 2019 18:39:42 GMT):
OK. Go is not supported so I will disable it here.

rjones (Tue, 24 Sep 2019 18:39:50 GMT):
https://lgtm.com/help/lgtm/analysis-faqs#which-languages-are-supported

rjones (Tue, 24 Sep 2019 18:40:48 GMT):
I disabled it on `fabric` and `fabric-ca`

MHBauer (Tue, 24 Sep 2019 19:06:17 GMT):
lol

MHBauer (Tue, 24 Sep 2019 19:13:03 GMT):
I don't have access to the setting, but can we enable the "dismiss stale pull request approvals when new commits are pushed" ?

MHBauer (Tue, 24 Sep 2019 19:13:16 GMT):
@swetha I think we want that ^

rjones (Tue, 24 Sep 2019 19:13:47 GMT):
I think you have the power to enable that?

MHBauer (Tue, 24 Sep 2019 19:13:55 GMT):
no

swetha (Tue, 24 Sep 2019 19:13:58 GMT):
its in the file isn't it

MHBauer (Tue, 24 Sep 2019 19:14:02 GMT):
I can see the settings tab, but I can't do anything with it.

MHBauer (Tue, 24 Sep 2019 19:14:13 GMT):
it's totally blank for options for me.

swetha (Tue, 24 Sep 2019 19:14:23 GMT):
https://github.com/hyperledger/fabric-chaincode-evm/blob/master/.github/stale.yml

rjones (Tue, 24 Sep 2019 19:14:46 GMT):
@MHBauer try now ;)

MHBauer (Tue, 24 Sep 2019 19:14:53 GMT):
that's inactivity

rjones (Tue, 24 Sep 2019 19:15:08 GMT):
Think of that file as a placeholder for now, OK?

MHBauer (Tue, 24 Sep 2019 19:15:19 GMT):
lol, I think it's reloading. just got a 500

rjones (Tue, 24 Sep 2019 19:15:30 GMT):
I added it when *fabric* were on Gerrit, and I didn't want valid PRs to get killed now

rjones (Tue, 24 Sep 2019 19:15:30 GMT):
I added it when `*fabric*` were on Gerrit, and I didn't want valid PRs to get killed now

MHBauer (Tue, 24 Sep 2019 19:16:03 GMT):
yay, okay, I can see the buttons now, I did want to discuss it a little, but I do think it's a thing we want on.

MHBauer (Tue, 24 Sep 2019 19:16:08 GMT):
thank you ry

rjones (Tue, 24 Sep 2019 19:16:19 GMT):
OK. I know that's different on different projects. Some of them don't want that, some do

swetha (Tue, 24 Sep 2019 19:17:08 GMT):
thanks ry!

swetha (Tue, 24 Sep 2019 19:17:34 GMT):
@MHBauer the option basically requires another review if code in the commit changes?

MHBauer (Tue, 24 Sep 2019 19:17:44 GMT):
that is my understanding, yes

MHBauer (Tue, 24 Sep 2019 19:17:50 GMT):
like for #9, you pushed an update

MHBauer (Tue, 24 Sep 2019 19:17:57 GMT):
and crhis approval is still in effect.

swetha (Tue, 24 Sep 2019 19:18:20 GMT):
i thought he approved it a second time

swetha (Tue, 24 Sep 2019 19:18:32 GMT):
i just rebased it now

MHBauer (Tue, 24 Sep 2019 19:18:34 GMT):
I don't see that.

swetha (Tue, 24 Sep 2019 19:18:55 GMT):
either way i think enabling the option seems correct

MHBauer (Tue, 24 Sep 2019 19:19:13 GMT):
okay, I'll clicky the button

MHBauer (Tue, 24 Sep 2019 19:19:56 GMT):
and now I kind of miss prow.

swetha (Tue, 24 Sep 2019 19:20:41 GMT):
your approval is after my most recent pushes right?

MHBauer (Tue, 24 Sep 2019 19:21:44 GMT):
that's what it appears

MHBauer (Tue, 24 Sep 2019 19:21:53 GMT):
your change 13 minutes, my approval 10 minutes

swetha (Tue, 24 Sep 2019 19:22:48 GMT):
i was confused with chris's approval too which is why im verifying now. the settings change doesn't affect current pull requests

MHBauer (Tue, 24 Sep 2019 19:23:01 GMT):
I mean

MHBauer (Tue, 24 Sep 2019 19:23:05 GMT):
yea, it doesn't go back in time

MHBauer (Tue, 24 Sep 2019 19:23:12 GMT):
it's an as happens thing.

MHBauer (Tue, 24 Sep 2019 19:23:41 GMT):
so now master merge pipeline is running.

MHBauer (Tue, 24 Sep 2019 19:23:43 GMT):
yay

MHBauer (Tue, 24 Sep 2019 19:23:46 GMT):
\o/

rjones (Tue, 24 Sep 2019 19:25:42 GMT):
if you want prow... :)

rjones (Tue, 24 Sep 2019 19:26:59 GMT):
do you want LGTM disabled on this repo?

swetha (Tue, 24 Sep 2019 19:27:34 GMT):
Yea I think we can disable LGTM if it doesn't support go yet

swetha (Tue, 24 Sep 2019 19:30:06 GMT):
Thanks Ry!

MHBauer (Tue, 24 Sep 2019 19:35:31 GMT):
I don't know what it does. says something about vulnerability analysis

MHBauer (Tue, 24 Sep 2019 19:56:04 GMT):
hmn, something is funky about the pipeline

MHBauer (Tue, 24 Sep 2019 19:56:29 GMT):
@BrettLogan is the pipeline job after a merge? or is it the pr/branch itself?

MHBauer (Tue, 24 Sep 2019 19:56:59 GMT):
Can we have it do both? one to ensure the branch builds at all, but then the merge to ensure it merges cleanly?

MHBauer (Tue, 24 Sep 2019 19:57:18 GMT):
I'm asking because I see references to non-existent lines in the build failure.

rjones (Tue, 24 Sep 2019 20:03:05 GMT):
(I'm going to drop out of here - if you need me, reach out)

MHBauer (Tue, 24 Sep 2019 20:03:53 GMT):
bye bye

rjones (Tue, 24 Sep 2019 20:05:54 GMT):
Has left the channel.

MHBauer (Tue, 24 Sep 2019 20:18:30 GMT):
I wonder if we have control of pre-recieve hooks.

MHBauer (Tue, 24 Sep 2019 20:18:48 GMT):
or maybe need a bot to scan the commit messaegs or something.

MHBauer (Tue, 24 Sep 2019 20:31:26 GMT):
besides lgtm, I'm more curious about dependabot and pull panda.

BrettLogan (Tue, 24 Sep 2019 20:33:00 GMT):
For PR's it runs all 3 jobs. For merges it runs just unit tests. I'd you want all 3 to run on a merge remove the conditions clauses

MHBauer (Tue, 24 Sep 2019 20:34:02 GMT):
hmn, not what I meant, but I was also being a dope.

MHBauer (Tue, 24 Sep 2019 20:34:12 GMT):
left out some new files, whoops!

MHBauer (Tue, 24 Sep 2019 20:34:28 GMT):
I like that the pipeline is in a ci directory

MHBauer (Fri, 27 Sep 2019 19:12:56 GMT):
@swetha @guoger not sure I agree with the setting `Require branches to be up to date before merging This ensures pull requests targeting a matching branch have been tested with the latest code. This setting will not take effect unless at least one status check is enabled (see below). ` in github

swetha (Fri, 27 Sep 2019 19:14:23 GMT):
Unless we can have github run the merging tests on the outcome of the merge before making the merge, I am okay with that setting

swetha (Fri, 27 Sep 2019 19:14:34 GMT):
I would like to get rid of all the merge commits though

MHBauer (Fri, 27 Sep 2019 19:14:57 GMT):
I disagree, don't edit my work.

MHBauer (Fri, 27 Sep 2019 19:18:13 GMT):
anyway, it's a learning process

swetha (Fri, 27 Sep 2019 19:23:30 GMT):
I meant is I would like the fast forward commits. We don't need to have merge commits if the code is forced to be rebased on the master before being merged in

swetha (Fri, 27 Sep 2019 19:23:30 GMT):
I meant I would like the fast forward commits. We don't need to have merge commits if the code is forced to be rebased on the master before being merged in

MHBauer (Fri, 27 Sep 2019 19:23:46 GMT):
True, but that's not what that does.

swetha (Fri, 27 Sep 2019 19:24:26 GMT):
I understand, that is a setting I would like. Otherwise I like having the forced rebase because it means we can see the tests run once before we merge the code in

MHBauer (Fri, 27 Sep 2019 19:25:02 GMT):
I can agree to that, but not what that does.

MHBauer (Fri, 27 Sep 2019 19:25:43 GMT):
Being a small enough project, anyway.

MHBauer (Fri, 27 Sep 2019 19:27:25 GMT):
lunch?

swetha (Fri, 27 Sep 2019 19:29:43 GMT):

Screen Shot 2019-09-27 at 12.29.19 PM.png

swetha (Fri, 27 Sep 2019 19:30:04 GMT):
I would like to dissable `Allow merge commits`, and `Automatically delete head branches`

swetha (Fri, 27 Sep 2019 19:30:16 GMT):
I think the last option should be left to the person who submitted the PR

MHBauer (Fri, 27 Sep 2019 19:30:59 GMT):
hmn, lemme see.

MHBauer (Fri, 27 Sep 2019 19:32:10 GMT):
ehh, it keeps my stuff clean.

swetha (Fri, 27 Sep 2019 19:32:39 GMT):
But not everyone would know that is the outcome

MHBauer (Fri, 27 Sep 2019 19:32:52 GMT):
So? it's merged? pull it back out yourself.

swetha (Fri, 27 Sep 2019 19:33:08 GMT):
deleting branches on someone else's repo doesn't seem right

MHBauer (Fri, 27 Sep 2019 19:33:11 GMT):
`Deleted branches will still be able to be restored.`

swetha (Fri, 27 Sep 2019 19:33:24 GMT):
I don't think that is good enough

MHBauer (Fri, 27 Sep 2019 19:33:24 GMT):
lemme see how true that is

swetha (Fri, 27 Sep 2019 19:33:40 GMT):
We shouldn't be deleting it to begin with

swetha (Fri, 27 Sep 2019 19:33:52 GMT):
You and me might like the feature since we contribute often and we have many branches

swetha (Fri, 27 Sep 2019 19:34:04 GMT):
Don't think that necessarily applies to everyone submitting a request

MHBauer (Fri, 27 Sep 2019 19:34:35 GMT):
I don't understand

MHBauer (Fri, 27 Sep 2019 19:34:50 GMT):
what are you doing to do with it after it's merged?

swetha (Fri, 27 Sep 2019 19:36:25 GMT):
its not a branch on our repo. I think that should mean we should not do anything destructive, regardless of whether we can recover from it or not

MHBauer (Fri, 27 Sep 2019 19:36:27 GMT):
I'm somewhat with you on dataloss, destruction of other people's information, but in practice, I don't understand.

swetha (Fri, 27 Sep 2019 19:37:15 GMT):
I am just thinking about it as other people's information. In practice don't 100% understand, but I can see it happen if they develop on their forked master and keep using that to submit PRs

swetha (Fri, 27 Sep 2019 19:37:43 GMT):
It shouldn't be up to us to dictate how someone does their branch management

MHBauer (Fri, 27 Sep 2019 19:38:33 GMT):
but they'd have to do something to it to it to submit it again

MHBauer (Fri, 27 Sep 2019 19:39:01 GMT):
I'm trying to think up the cases.

MHBauer (Fri, 27 Sep 2019 19:39:06 GMT):
We're going to force them to rebase

MHBauer (Fri, 27 Sep 2019 19:39:15 GMT):
then after it's merged in to master

MHBauer (Fri, 27 Sep 2019 19:39:32 GMT):
anything they create, they have to pull and rebase

MHBauer (Fri, 27 Sep 2019 19:39:59 GMT):
I dunno. I don't feel strongly, but I do end up with a zillion branch references.

MHBauer (Fri, 27 Sep 2019 19:40:13 GMT):
for the other thing, rebasing

MHBauer (Fri, 27 Sep 2019 19:40:37 GMT):
I'd be fine with that button if it didn't 'rebase-anyway' even if the current commit was up to date.

MHBauer (Fri, 27 Sep 2019 19:40:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-evm?msg=MAak6WPbruox4kjiD) it doesn't rebase unless someone clicks rebase

MHBauer (Fri, 27 Sep 2019 19:40:53 GMT):
So, if we want to do manual merging into master, that's fine, but don't use the button.

swetha (Fri, 27 Sep 2019 20:41:52 GMT):
So perhaps we turn off the option you mentioned about and then we only allow rebase merging that might solve the problem?

MHBauer (Fri, 27 Sep 2019 20:42:58 GMT):
I dunno. I need to experiment again.

MHBauer (Fri, 27 Sep 2019 20:43:18 GMT):
The answer might just be, "don't use the button, try and do things manually"

MHBauer (Fri, 27 Sep 2019 20:43:32 GMT):
I'm comfortable with git, but others might not be.

swetha (Fri, 27 Sep 2019 20:45:46 GMT):
manually as in locally? I didn't think we are allowed to do that directly, since it is a protected branch

MHBauer (Fri, 27 Sep 2019 20:55:36 GMT):
hmn, haven't tried. maybe when yours is ready

MHBauer (Fri, 27 Sep 2019 21:03:44 GMT):
@swetha the checks didn't run.

MHBauer (Fri, 27 Sep 2019 21:03:53 GMT):
weird

swetha (Fri, 27 Sep 2019 21:05:30 GMT):
checks are still running. maybe azp doesn't have any free vms right now?

swetha (Fri, 27 Sep 2019 21:06:00 GMT):
one thing we can look into is to not run code checks on doc changes

BrettLogan (Fri, 27 Sep 2019 21:14:33 GMT):
There is a 10 parallel job limit in AZP by default. If you need more jobs, I can open a support ticket and request they bump it up

MHBauer (Fri, 27 Sep 2019 22:28:53 GMT):
I can't see anything running right now

MHBauer (Fri, 27 Sep 2019 22:29:18 GMT):
@BrettLogan and I don't see any related to the push she made.

MHBauer (Fri, 27 Sep 2019 22:29:30 GMT):
so if it's 10 jobs for the whole org, we're never going to have enough.

MHBauer (Fri, 27 Sep 2019 22:29:48 GMT):
or we need a button to push it if it doesn't see anything.

BrettLogan (Fri, 27 Sep 2019 22:33:14 GMT):
Ah. I misunderstood. I thought Swetha was saying her jobs were queued but not running. In which case AZP may not report back to the checks API that the job had started. You can also comment on your PR with `/azp list` to see available comment triggers. Though we may not have permissions set up correctly for that, I have to check. As Maintainers on the repo you may have a high enough level to do so.

BrettLogan (Fri, 27 Sep 2019 22:33:26 GMT):
And the 10 jobs is per project, not for the whole org

MHBauer (Fri, 27 Sep 2019 22:49:59 GMT):
ooh

MHBauer (Fri, 27 Sep 2019 22:50:06 GMT):
comment triggers, did not know that was a thing.

MHBauer (Fri, 27 Sep 2019 22:50:49 GMT):
ah, okay, and for the record, as context, we're specifically talking about this pr https://github.com/hyperledger/fabric-chaincode-evm/pull/12

MHBauer (Fri, 27 Sep 2019 22:52:28 GMT):
that was very nice. thank you @BrettLogan :ok_hand:

BrettLogan (Fri, 27 Sep 2019 22:58:40 GMT):
Yea. If you implement stages you can get much more granular on what you can control via comments. Currently your only option is to trigger the entire pipeline.

MHBauer (Sat, 28 Sep 2019 00:19:11 GMT):
more to read about.

cbf (Wed, 09 Oct 2019 18:13:08 GMT):
curious as to whether there are any inhibitors to moving off Gerrit for the evm chaincode... thoughts?

BrettLogan (Wed, 09 Oct 2019 18:19:26 GMT):
We actually migrated EVM off Gerrit about two weeks ago

MHBauer (Wed, 09 Oct 2019 18:29:13 GMT):
:+1:

MHBauer (Wed, 09 Oct 2019 18:29:43 GMT):
If there's anything left over there, we're not concerned and it can be turned off.

BrettLogan (Wed, 09 Oct 2019 18:31:26 GMT):
https://gerrit.hyperledger.org/r/admin/repos

BrettLogan (Wed, 09 Oct 2019 18:31:32 GMT):
Nope, the repo is marked read-only

MHBauer (Wed, 09 Oct 2019 18:46:04 GMT):
I have no concerns.

MHBauer (Wed, 09 Oct 2019 18:46:18 GMT):
@cbf are we advertising gerrit somewhere that needs to be corrected?

MHBauer (Wed, 09 Oct 2019 18:46:32 GMT):
older blogs, probably

silasdavis (Wed, 09 Oct 2019 19:33:42 GMT):
@swetha cc https://github.com/perlin-network/life/pull/93

silasdavis (Wed, 09 Oct 2019 19:33:51 GMT):
avoids replace directive pain

swetha (Wed, 09 Oct 2019 19:35:11 GMT):
perfect! i was just looking into how the burrow upgrade will look in the evmcc

MHBauer (Wed, 09 Oct 2019 19:46:48 GMT):
???

MHBauer (Wed, 09 Oct 2019 19:48:57 GMT):
@klenik @swetha https://github.com/hyperledger/fabric-chaincode-evm/pull/16 looks like we're still after a test case to trigger it?

swetha (Wed, 09 Oct 2019 20:04:44 GMT):
Yes we need to play around with the test case a little more

swetha (Wed, 09 Oct 2019 20:05:38 GMT):
I just did a quick test with the same inputs as Attila used. I have not investigated why it didn't cause the problem. I will look into it soon

MHBauer (Wed, 09 Oct 2019 20:17:21 GMT):
I'm not sure time is well spent on finding an exact case of fabric certificates that cause the issue.

swetha (Wed, 09 Oct 2019 20:27:16 GMT):
If I have to look for another combination, I am not going to add the test. I need to make sure I didn't miss a mock or something

klenik (Wed, 09 Oct 2019 20:29:49 GMT):
@swetha Could you please send me the link to your fork/branch you're experimenting on with the tests? I'll also try to reproduce the issue in that environment

swetha (Wed, 09 Oct 2019 20:32:16 GMT):
@klenik I just added a wip commit on the pr branch: https://github.com/swetharepakula/fabric-chaincode-evm/tree/event-name-error

MHBauer (Wed, 09 Oct 2019 21:25:24 GMT):
it's something we can generate once and reuse. we're looking for a 8byte pattern that fails utf8.Valid()

MHBauer (Wed, 09 Oct 2019 21:25:43 GMT):
grr, I didn't want a thread

cbf (Thu, 10 Oct 2019 15:04:02 GMT):
I guess I missed the memo;-) been traveling too much

cbf (Thu, 10 Oct 2019 15:04:18 GMT):
but in the Fabric docs, we don't mention this

cbf (Thu, 10 Oct 2019 15:04:40 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html

cbf (Thu, 10 Oct 2019 15:09:01 GMT):
eg we point in our CONTRIBUTING.md to the doc above, yet that does not mention that we have transitioned to GitHub

swetha (Thu, 10 Oct 2019 15:15:17 GMT):
I missed both of those. I will make some PRs to have those be more accurate

swetha (Thu, 10 Oct 2019 19:22:23 GMT):
submitted this https://gerrit.hyperledger.org/r/#/c/fabric/+/33937/ to fix fabric docs

swetha (Wed, 16 Oct 2019 15:03:59 GMT):
@here Fabric Chaincode EVM Meeting starting now https://zoom.us/my/hyperledger.community.backup

swetha (Wed, 16 Oct 2019 15:04:26 GMT):
Agenda: https://wiki.hyperledger.org/display/fabric/2019-10-16

swetha (Thu, 17 Oct 2019 18:02:46 GMT):
@MHBauer we did want to enable this feature on github right? ``` Dismiss stale pull request approvals when new commits are pushed ```

MHBauer (Thu, 17 Oct 2019 19:27:37 GMT):
yes, right? I agree to that. We can put all the settings in a jira and make it official_

swetha (Thu, 17 Oct 2019 19:32:41 GMT):
Just verifying before i turn it on. It would match what we had in gerrit

MHBauer (Thu, 17 Oct 2019 19:41:58 GMT):
make sense to me to match that as well.

swetha (Thu, 17 Oct 2019 20:27:54 GMT):
only problem is it doesn't differentiate a rebase

MHBauer (Thu, 17 Oct 2019 22:35:39 GMT):
ah, no biggie.

MHBauer (Thu, 17 Oct 2019 22:35:48 GMT):
just hit the button before that, or do it manually.

MHBauer (Thu, 17 Oct 2019 22:58:24 GMT):
not sure if I have tried a manual rebase, but the worst that happens is you manually close the issue

swetha (Fri, 18 Oct 2019 00:25:21 GMT):
I did the manual rebase and force pushed to the branch. it made the review required

swetha (Fri, 18 Oct 2019 00:25:48 GMT):
Next time I will try the button. Not sold on letting github rebase my branches, but we can give it try on a simple pr

MHBauer (Fri, 18 Oct 2019 01:41:28 GMT):
not push to branch, push to master.

swetha (Fri, 18 Oct 2019 04:16:49 GMT):
Oh that's right, i should have tried that

BrettLogan (Wed, 30 Oct 2019 12:46:05 GMT):
Has left the channel.

hawkinggg (Mon, 04 Nov 2019 07:12:30 GMT):
Has joined the channel.

lehors (Wed, 20 Nov 2019 16:01:41 GMT):
hi there

lehors (Wed, 20 Nov 2019 16:01:44 GMT):
is there a call today?

swetha (Wed, 20 Nov 2019 16:06:26 GMT):
Agenda: https://wiki.hyperledger.org/display/fabric/2019-11-19

greg2git (Wed, 20 Nov 2019 16:40:51 GMT):
Has joined the channel.

greg2git (Wed, 20 Nov 2019 16:41:15 GMT):
hello guys, great call, thank you

swetha (Wed, 20 Nov 2019 19:11:27 GMT):
@greg2git Thank you for joining!

MHBauer (Thu, 21 Nov 2019 21:24:10 GMT):
hi @greg2git thanks for beingthere.

maciejjedrzejczyk (Tue, 17 Dec 2019 07:07:38 GMT):
Has joined the channel.

swetha (Wed, 18 Dec 2019 16:01:16 GMT):
Fabric EVM Meeting today. Agenda: https://wiki.hyperledger.org/display/fabric/2019-12-18 Zoom: https://zoom.us/j/6223336701

swetha (Wed, 18 Dec 2019 16:01:16 GMT):
Fabric EVM Meeting now. Agenda: https://wiki.hyperledger.org/display/fabric/2019-12-18 Zoom: https://zoom.us/j/6223336701

maciejjedrzejczyk (Thu, 19 Dec 2019 06:20:42 GMT):
Hi, could you please point me to an up to date tutorial that explains how to deploy all components of Fabric EVM?

swetha (Thu, 19 Dec 2019 14:58:30 GMT):
Hi @maciejjedrzejczyk, the tutorial in the repo should be up to date. If you run into any issues, please let us know

ChaoLiu (Sat, 21 Dec 2019 17:17:47 GMT):
Has joined the channel.

MHBauer (Thu, 09 Jan 2020 23:00:37 GMT):
go 1.11 is already not being updated anymore. I need to make a record of whatever upstream policy is so I can stop thinking about this.

MHBauer (Wed, 15 Jan 2020 16:01:29 GMT):
meeting comping up as soon as I load zoom.

MHBauer (Wed, 15 Jan 2020 16:34:16 GMT):
Thanks for attending, here's the meeting page with recording https://wiki.hyperledger.org/display/fabric/2020-01-15

Ewkoll (Mon, 17 Feb 2020 09:19:23 GMT):
Has joined the channel.

Franz (Fri, 28 Feb 2020 15:58:02 GMT):
Has joined the channel.

Abhishekkishor (Thu, 12 Mar 2020 19:44:20 GMT):
Has joined the channel.

MHBauer (Thu, 19 Mar 2020 15:13:06 GMT):
Is there a meeting now? I can't find the slack channel

Franz (Fri, 20 Mar 2020 11:25:38 GMT):
Hi, I'm trying web31.2.0 to interact with the network, but calling methods of smart contract the output is [ [Object] ]. Do you know why ?

gokulalex (Fri, 20 Mar 2020 12:05:16 GMT):
Has joined the channel.

MHBauer (Fri, 20 Mar 2020 18:13:28 GMT):
The web3 we have in our tests is very old. Before 1.0

Franz (Sun, 22 Mar 2020 18:02:53 GMT):
I know. In all the examples is used web3@0.20.2. There's some guide or example that use web3@1.0 or greater to deploy and test smart contract ?

swetha (Tue, 24 Mar 2020 18:19:38 GMT):
No we don't have any samples for 1.0 or greater, but 1.0 and greater does work

Franz (Tue, 24 Mar 2020 18:40:49 GMT):
Thanks

Franz (Tue, 24 Mar 2020 19:09:51 GMT):
Hello I'm running a simple smart contract that add or spend points among registered users _(address, name, points, isRegistered)_. When I run the clients and call the methods the _eth address_ is always the same, calling `web3.eth.getAccounts(console.log)` there's always just one account from beginning to end of the console running. *1)* If I call `web3.eth.accounts.create()` what happens to the created accounts ? *2)* The only one account is associated to fab3 instance running? *3)* How can I create and call methods from different accounts (_e.g `registerUser `with different msg.sender address_) in order to test my smart contract?

Franz (Tue, 24 Mar 2020 19:09:51 GMT):
Hello I'm running a simple smart contract that add or spend points among registered users _(address, name, points, isRegistered)_. When I run the clients and call the methods the _eth address_ is always the same, calling `web3.eth.getAccounts(console.log)` there's always just one account from beginning to end of the console running. If I call `web3.eth.accounts.create()` what happens to the created accounts ? The only one account is associated to fab3 instance running? How can I create and call methods from different accounts (_e.g `registerUser `with different msg.sender address_) in order to test my smart contract?

swetha (Tue, 24 Mar 2020 20:56:08 GMT):
Each fab3 can only have one account at a time. It is one to one with the user that the fab3 instance is started with. Fab3 puts the sender address and ignores what is passed in

swetha (Tue, 24 Mar 2020 20:56:45 GMT):
If you want more accounts, you need to have multiple fab3 instances and more users created in fabric

swetha (Tue, 24 Mar 2020 21:00:36 GMT):
https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Fab3_Instructions.md

swetha (Tue, 24 Mar 2020 21:01:44 GMT):
Those are the subset of the ethereum json rpc api we support and the current restrictions

Franz (Thu, 26 Mar 2020 10:01:56 GMT):
Thanks a lot :) I finally understood

Franz (Tue, 31 Mar 2020 11:44:37 GMT):
Hello everybody. I've a doubt about` loyalty-points-evm-fabric`. How the example handle the membership application side. I understand how works fab3 and integration but How client recognize the User(belong to Org1 or Org2) that call method inside smart contract. e.g the method registerMember could be called only by User belonging to Org2 and so on. so how application filter the request ?

swetha (Wed, 01 Apr 2020 07:18:07 GMT):
I am not familiar with the details of that example, but I think the application roles don't necessarily translate into Fabric users. The app is more defining users from the app's perspective. I recommend asking one of the contributors of the project for more information.

matanyahu (Mon, 06 Apr 2020 17:54:37 GMT):
Has joined the channel.

Franz (Fri, 10 Apr 2020 09:29:35 GMT):
Hello there's a way to link metamask (own eth address) to Fab3 in order to interact with ethereum network too ? My goal is move erc20 token on a ethereum network starting from fabric chaincode. there's a way to do that ?

MHBauer (Thu, 16 Apr 2020 21:30:22 GMT):
No, fab3 talks to fabric network, and there is no concept of talking to a mainnet or fork.

Franz (Thu, 23 Apr 2020 15:58:04 GMT):
Hi. If I run the chaincode-evm in net mode the only way to see all transactions logs is to run `docker logs containerID` ? There's a way (e.g using fab3) to print all blockchain transactions log at higher level ?

MHBauer (Thu, 23 Apr 2020 17:30:40 GMT):
I am not sure what is meant by "net mode". Which container logs are you looking at? The chaincode? Which transaction logs are you trying to look for? Fabric or evm? We store evm logs into fabric logs, but in a somewhat custom way as json. for evm logs through fab3 we've implemented the rpc call https://github.com/hyperledger/fabric-chaincode-evm/blob/master/Fab3_Instructions.md#eth_getLogs There is a partially completed implementation of the asynchronous log follower, https://github.com/hyperledger/fabric-chaincode-evm/pull/27 but it still needs some work.

Franz (Fri, 24 Apr 2020 09:31:24 GMT):
I saw in some opened topics(e.g on stackoverflow ) that talk about "net mode" and "dev mode". "net mode" should mean the standard mode running the peers and all net components inside docker containers. ``` ``` I'm trying to look the blockchain transactions log, when an endorsing peer verify a transaction and the orderer release a new block. at "lower level". If I look inside docker containers I could see all the transactions processed and block released, but can I see that informations at "higher level" in order to insert that transactions log inside my dapp ? I tryed eth_getLogs in several way but it return "can't find method getLogs" message

Franz (Fri, 24 Apr 2020 09:31:24 GMT):
I saw in some opened topics(e.g on stackoverflow ) that talk about "net mode" and "dev mode". "net mode" should mean the standard mode running the peers and all net components inside docker containers. ``` ``` I'm trying to look the blockchain transactions log, when an endorsing peer verify a transaction and the orderer release a new block. at "lower level". If I look inside docker containers I could see all the transactions processed and block released, but can I see that informations at "higher level" in order to insert that transactions log inside my dapp ? ``` I tryed eth_getLogs in several way but it return "can't find method getLogs" message```

Franz (Fri, 24 Apr 2020 09:31:24 GMT):
I saw in some opened topics(e.g on stackoverflow ) that talk about "net mode" and "dev mode". "net mode" should mean the standard mode running the peers and all net components inside docker containers. ``` ``` I'm trying to look the blockchain transactions log, when an endorsing peer verify a transaction and the orderer release a new block. at "lower level". If I look inside docker containers I could see all the transactions processed and block released, but can I see that informations at "higher level" in order to insert that transactions log inside my dapp ? ``` I tryed eth_getLogs in several way but it return "can't find method getLogs" message

swetha (Fri, 24 Apr 2020 18:30:42 GMT):
So from the fabric chaincode evm side there is no change based on the modes you mentioned. I am not familiar with those terms. In general the evm chaincode logs will be found looking at the docker logs for that container, or where the other chaincode logs are. Fab3 only logs to stdout right now and only shows INFO level logging. At the moment neither the evm and fab3 log every request so having a transaction log would not work. You can query for all the blocks using fab3 and json rpc api.

Franz (Sat, 25 Apr 2020 08:19:44 GMT):
Thanks a lot for the help 🙂

Franz (Sat, 25 Apr 2020 08:30:53 GMT):
At this link https://wiki.hyperledger.org/display/fabric/Raw+Transaction+Design I saw that @MHBauer conceptualize to introduce metamask in raw transaction process. There's architecture design limit to develop it ?

MHBauer (Mon, 27 Apr 2020 17:37:05 GMT):
That's information we came up together of the work required. It was never put to full planning.

magdasta (Wed, 06 May 2020 14:13:30 GMT):
Has joined the channel.

magdasta (Wed, 06 May 2020 14:13:30 GMT):
Hi! I've been playing around with HLF for only a few days, so please forgive me if it's a lame question, but I couldn't find an answer. Is it possible to use evmcc with fabric 2.0? If so, are there any tutorials or docs? And if not, when it's planned to be supported?

MHBauer (Wed, 06 May 2020 18:04:36 GMT):
It's a go chaincode, so I can't think of any reason it wouldn't work.

abrinckm (Tue, 12 May 2020 13:47:21 GMT):
Has joined the channel.

Franz (Wed, 13 May 2020 08:20:30 GMT):
*[Fab3]* Hello I build and run a new network with 3 Orgs( 1 peer per org ) and 2 channels (channel12 and channel23). When I run the fab3 proxy appear the error "`Error: Failed to create Fabric SDK Client: failed to initialize configuration: unable to load endpoint config: failed to initialize endpoint config from config backend: network configuration load failed: failed to load channel configs: failed to load channel peers: unable to find MSP ID for peer : peer0.org3.example.com`" . I modified the config file `network-sdk-config.yaml` in order to add peer0.org3.example.com and the channel12 and channel23. Some tips for that error ?

Franz (Wed, 13 May 2020 15:22:47 GMT):
SOLVED. It 'was a simple typo :grimacing:

MHBauer (Wed, 13 May 2020 16:26:37 GMT):
Oh, I hate those so much.

Franz (Fri, 15 May 2020 09:05:49 GMT):
There's a way to run transaction of an ERC20 token over a public Blockchain(Ethereum) starting from my private fabric chaincode(smart contract) ?

conanoc (Tue, 19 May 2020 10:07:52 GMT):
Has left the channel.

MHBauer (Tue, 19 May 2020 19:37:05 GMT):
You ought to be able to run erc20 contracts in evm-chaincode, but there is no connection from chaincode-evm to public networks. That would have to be done outside of chaincode-evm.

Franz (Wed, 20 May 2020 08:56:50 GMT):
Thanks for the reply. I would like to study if it's possible to implement a mapping mechanism between eth wallets and fabric users, storing the eth wallet(couple of keys) instead of generate it on the fly when run fab3, and link it to a x.509 certificate of fabric user. I saw that on github repo of Fab3 there's not a docs about files goal, but just how to use it. Where is generated the eth wallet during fab3 running ? in types.go ? and where is stored the keys once it is generated ? Every other kind of tips and advise about argument are so much appreciate :)

MHBauer (Wed, 20 May 2020 15:45:45 GMT):
the mapping mecahism would be the msp from the diagram.

MHBauer (Wed, 20 May 2020 15:46:07 GMT):
The address in fab3 is generated from the fabric auth

MHBauer (Wed, 20 May 2020 18:09:33 GMT):
https://github.com/hyperledger/fabric-chaincode-evm/blob/59deb68bba4dd870905ee57aca767a7421bd4b56/evmcc/evmcc.go#L205-L233

Franz (Wed, 20 May 2020 18:30:35 GMT):
Thanks a lot for advise. I pay attention to the code during this days. So approximately it should work in the following way: the fab3 run -> call account function in evmcc chaincode -> the account function check identity and generate an eth address starting from "IdentityToAddress" -> this eth address is used to invoke smart contract

Franz (Wed, 20 May 2020 18:30:35 GMT):
so the eth account generated isn't completly random but "semi-random" generated starting from address of own fabric certificate ?

MHBauer (Wed, 20 May 2020 19:19:13 GMT):
must recall that fab3 is using a fabric identity

MHBauer (Wed, 20 May 2020 20:53:50 GMT):
that is passed through to evmcc, which unpacks it to convert to a evm address.

Franz (Thu, 21 May 2020 08:15:44 GMT):
so the eth account address generated isn't completly random but "semi-random"?

MHBauer (Thu, 21 May 2020 14:22:56 GMT):
more arbitrary, than random, https://github.com/hyperledger/fabric-chaincode-evm/blob/59deb68bba4dd870905ee57aca767a7421bd4b56/evmcc/address/converter.go

MHBauer (Thu, 21 May 2020 14:23:04 GMT):
sha3 of public key

swetha (Thu, 21 May 2020 14:42:25 GMT):
One other thing to note is that the eth address used for the from field is always rewritten by fab3 to use the address generated from the public key of the transaction

Franz (Fri, 22 May 2020 10:00:15 GMT):
So correct me if I'm wrong. Fab3 instance run -> connect as UserX of OrgX to evmcc -> evm chaincode check identity, take fabric identity, umarshall keyPub and perform sha3(keyPub) to generate eth address -> from now each chaincode invokation is done using eth account chaincode side otherwise fabric network side use fabric identity. my dubts is 1. where is stored the eth account ? 2. the fabric auth is performed chaincode side or network side ?

MHBauer (Fri, 22 May 2020 17:28:14 GMT):
not sure what's mean by "where is eth account stored" account is an address, and the address generation has been shown above. 2. fabric auth is done during fab3 -> fabric communication.

swetha (Fri, 22 May 2020 18:24:36 GMT):
The eth account is not stored anywhere. Every fabric transaction needs a fabric identity, so using that public key which is sent with the transaction, fabric knows the account. The account address is always generated on the fly.

Franz (Sat, 23 May 2020 08:19:06 GMT):
Okay so there isn't created a real eth wallet with a couple of keys (with a storing mechanism for KeyPrivate). but it's created just the eth public key used for transaction over the evm ?

MHBauer (Wed, 27 May 2020 00:46:01 GMT):
yes, correct.

swetha (Wed, 27 May 2020 01:01:19 GMT):
There are fabric pub/priv key pair that is used. That private key is needed to sign the fabric transaction which has the evm transaction within it

SuperSeiyan (Fri, 07 Aug 2020 06:08:45 GMT):
Has joined the channel.

charyorde (Mon, 17 Aug 2020 01:06:33 GMT):
Anyone has experience building a custom token on EVM with no gas, runs on own VM and can interoperate with IBM Blockchain? Please DM for project

charyorde (Tue, 25 Aug 2020 16:56:20 GMT):
@MHBauer With fabric release 2.2, which docker file do I add the fabric-chaincode-evm? There's no docker-compose-cli in fabric release 2.2

MHBauer (Tue, 25 Aug 2020 18:38:47 GMT):
what are you working through?

charyorde (Tue, 25 Aug 2020 19:00:35 GMT):
I don't your question

MHBauer (Tue, 25 Aug 2020 19:04:32 GMT):
What are you doing? Following a guide? Where does comopse-cli figure in to your process?

charyorde (Tue, 25 Aug 2020 19:15:03 GMT):
https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md

MHBauer (Tue, 25 Aug 2020 19:17:05 GMT):
ah, yes, we have not migrated to a 2.0 based process nor the `test-network` instead of `first-network`.

charyorde (Tue, 25 Aug 2020 19:17:13 GMT):
I'm using the test-network on relese 2.2

MHBauer (Tue, 25 Aug 2020 19:17:30 GMT):
we should probably not be linking to master for our links.

NizomjonKhajiev (Mon, 31 Aug 2020 13:09:36 GMT):
Has joined the channel.

NizomjonKhajiev (Mon, 31 Aug 2020 13:09:37 GMT):
Hi

sstone1 (Thu, 03 Sep 2020 07:13:57 GMT):
Has left the channel.

gregdhill (Thu, 03 Sep 2020 13:34:12 GMT):
Has left the channel.

jaromil (Thu, 08 Oct 2020 15:19:15 GMT):
Has left the channel.

ErnestoGomez (Wed, 11 Nov 2020 17:16:35 GMT):
Has joined the channel.

ErnestoGomez (Wed, 11 Nov 2020 17:16:35 GMT):
Hello, How can I get the address from a public key? I tried using keccak256(PuK), Sha2-256(PuK), and Sha3-256(PuK) but no result match the address associated with this PuK

ErnestoGomez (Mon, 16 Nov 2020 18:15:50 GMT):
Ok, I got the solution Sha3-256(0x3059301306072a8648ce3d020106082a8648ce3d030107034200:PubK)

ErnestoGomez (Mon, 16 Nov 2020 18:16:07 GMT):
concatenate 3059301306072a8648ce3d020106082a8648ce3d030107034200 and the publickey

pouya (Sun, 29 Nov 2020 11:02:10 GMT):
Has joined the channel.

bh4rtp (Sun, 10 Jan 2021 00:47:46 GMT):
Hi, what is the use of fabric-evm? I am using the SDK accessing the fabric network.

HansrajRami (Mon, 11 Jan 2021 15:35:59 GMT):
Has joined the channel.

HansrajRami (Tue, 12 Jan 2021 07:24:06 GMT):
Hi I was setting up this on fabric 2.2.1 evmcc chaincode working perfect But fab3 proxy is not running Does fab3 proxy works with fabric 2.2.x ??

HansrajRami (Tue, 12 Jan 2021 13:13:23 GMT):
I've tried this example https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md With first network example in fabric samples repo But fabric version is 2 I am having this error while starting fab3 proxy ``` Error: Failed to create Fabric SDK Channel Client: failed to create channel context: failed to get client context to create channel client: getting private key from cert failed: Failed getting key for SKI [[195 186 252 66 222 59 87 132 88 84 30 189 208 4 67 84 65 93 59 65 204 231 202 219 251 121 53 38 15 172 231 228]]: Key with SKI c3bafc42de3b578458541ebdd0044354415d3b41cce7cadbfb7935260face7e4 not found in /tmp/msp/keystore ```

barankilic (Sun, 31 Jan 2021 15:54:10 GMT):
Has joined the channel.

CANEREMEC (Fri, 26 Mar 2021 08:32:56 GMT):
Has joined the channel.

RobertBetschinger (Fri, 28 May 2021 10:21:16 GMT):
Has joined the channel.

jimthematrix (Mon, 07 Jun 2021 16:01:53 GMT):
Has left the channel.

Shritesh99 (Fri, 16 Jul 2021 04:58:27 GMT):
Has joined the channel.

Shritesh99 (Fri, 16 Jul 2021 05:12:59 GMT):
Hello, I am the Mentee for this year's "Implement cross-chain contract invocation using Servicemesh way" project. I have installed fabric EVM chaincode on Fabric 2.2, I am not able to invoke the EVM starting transaction using the command: ``` peer chaincode invoke -o localhost:7050 --tls --cafile $ORDERER_CA -C mychannel -n evmcc --peerAddresses localhost:7051 --tlsRootCertFiles $PEER0_ORG1_CA --peerAddresses localhost:9051 --tlsRootCertFiles $PEER0_ORG2_CA -c '{"Args":[]}' ``` I have also logged into thechaincode docker container and here are the logs of it. ``` 2021-07-16 05:03:10.185 UTC [shim] setupChaincodeLogging -> WARN 001 Error: logger: invalid log level for shim log level: warn2021-07-16 05:03:10.185 UTC [shim] setupChaincodeLogging -> INFO 002 Chaincode (build level: 2.3.2) starting up ... ```

Shritesh99 (Fri, 16 Jul 2021 05:12:59 GMT):
Hello, I am the Mentee for this year's "Implement cross-chain contract invocation using Servicemesh way" project. I have installed fabric EVM chaincode on Fabric 2.2, I am not able to invoke the EVM starting transaction using the command: ```peer chaincode invoke -o localhost:7050 --tls --cafile $ORDERER_CA -C mychannel -n evmcc --peerAddresses localhost:7051 --tlsRootCertFiles $PEER0_ORG1_CA --peerAddresses localhost:9051 --tlsRootCertFiles $PEER0_ORG2_CA -c '{"Args":[]}' ``` I have also logged into thechaincode docker container and here are the logs of it. ``` 2021-07-16 05:03:10.185 UTC [shim] setupChaincodeLogging -> WARN 001 Error: logger: invalid log level for shim log level: warn2021-07-16 05:03:10.185 UTC [shim] setupChaincodeLogging -> INFO 002 Chaincode (build level: 2.3.2) starting up ... ```

Shritesh99 (Fri, 16 Jul 2021 05:12:59 GMT):
Hello, I am the Mentee for this year's "Implement cross-chain contract invocation using Servicemesh way" project. I have installed fabric EVM chaincode on Fabric 2.2, I am not able to invoke the EVM starting transaction using the command: ``` peer chaincode invoke -o localhost:7050 --tls --cafile $ORDERER_CA -C mychannel -n evmcc --peerAddresses localhost:7051 --tlsRootCertFiles $PEER0_ORG1_CA --peerAddresses localhost:9051 --tlsRootCertFiles $PEER0_ORG2_CA -c '{"Args":[]}' ``` I have also logged into thechaincode docker container and here are the logs of it. ``` 2021-07-16 05:03:10.185 UTC [shim] setupChaincodeLogging -> WARN 001 Error: logger: invalid log level for shim log level: warn 2021-07-16 05:03:10.185 UTC [shim] setupChaincodeLogging -> INFO 002 Chaincode (build level: 2.3.2) starting up ... ```

Shritesh99 (Fri, 16 Jul 2021 05:12:59 GMT):
Hello, I am the Mentee for this year's "Implement cross-chain contract invocation using Servicemesh way" project. I have installed fabric EVM chaincode on Fabric 2.2, I am not able to invoke the EVM starting transaction using the command: ``` peer chaincode invoke -o localhost:7050 --tls --cafile $ORDERER_CA -C mychannel -n evmcc --peerAddresses localhost:7051 --tlsRootCertFiles $PEER0_ORG1_CA --peerAddresses localhost:9051 --tlsRootCertFiles $PEER0_ORG2_CA -c '{"Args":[]}' ``` I have also logged into the EVM chaincode docker container and here are the logs of it. ``` 2021-07-16 05:03:10.185 UTC [shim] setupChaincodeLogging -> WARN 001 Error: logger: invalid log level for shim log level: warn 2021-07-16 05:03:10.185 UTC [shim] setupChaincodeLogging -> INFO 002 Chaincode (build level: 2.3.2) starting up ... ```

kaushambi (Fri, 20 Aug 2021 13:57:55 GMT):
Has joined the channel.

maciejjedrzejczyk (Wed, 06 Oct 2021 12:16:08 GMT):
Hi, I am considering the use of fabric-evm in my future project but wanted to confirm if it has been successfully tested against HLF 2.x (preferrably 2.3)?

barankilic (Mon, 11 Oct 2021 12:02:41 GMT):
On the projects Github page (https://github.com/hyperledger/fabric-chaincode-evm), Hyperledger Fabric v1.4 is listed as dependency. I _guess_ it will not work with Fabric 2.x. I am not related to this project, but it looks like it is currently not maintained (or the development is finished and there is no need to change things.)

gsarkar (Fri, 10 Dec 2021 08:23:36 GMT):
Has joined the channel.

gsarkar (Fri, 10 Dec 2021 08:23:37 GMT):
I have followed the link ( https://github.com/hyperledger/fabric-chaincode-evm ) to install EVM chaincode on Hyperledger Fabric. I also deployed the ERC721 solidity smart contract on the EVM chaincode. While querying the owner address through the function in the ERC721 smart contract, I'm getting the owner address as "AAAAAAAAAAAAAAAAMeGlXRSvGKRwCB3ufvC6Xg6YlE0=" from EVM chaincode compared to the owner address of "0x5B38Da6a701c568545dCfcB03FcB875f56beddC4" from the same ERC721 smart contract on Ethereum. It looks like there are 2 different encoding standards followed between EVM and Ethereum. Please suggest how to resolve the issue. Please note that I'm also getting additional characters like nulls and line breaks during the response from ERC721 smart contract on EVM chaincode.

tkuhrt (Mon, 03 Jan 2022 20:31:21 GMT):
@MHBauer @swetha : Is the EVM chaincode still supported? We are looking to move Hyperledger Burrow to a Dormant state, and I would like to understand the impact to this integration.

tkuhrt (Mon, 03 Jan 2022 20:31:21 GMT):
@MHBauer @swetha : Is the EVM chaincode still supported? We are looking to move Hyperledger Burrow to a Dormant state (at the request of the maintainers), and I would like to understand the impact to this integration.

rjones (Wed, 23 Mar 2022 17:35:17 GMT):