rjones (Fri, 28 Feb 2020 23:02:04 GMT):
hartm

rjones (Fri, 28 Feb 2020 23:02:49 GMT):
User User_1 added by rjones.

rjones (Fri, 28 Feb 2020 23:02:49 GMT):
User User_2 added by rjones.

rjones (Fri, 28 Feb 2020 23:03:41 GMT):
shemnon

rjones (Fri, 28 Feb 2020 23:03:46 GMT):
have fun!

hartm (Fri, 28 Feb 2020 23:57:43 GMT):
Thanks @rjones !

hartm (Fri, 28 Feb 2020 23:58:02 GMT):
Adding @seanyoung

rjones (Fri, 28 Feb 2020 23:59:15 GMT):
I don't see a way to move or copy the previous conversation over, so it's up to you all to handle the `state`

rjones (Fri, 28 Feb 2020 23:59:35 GMT):
side-channel context switching attacks on your cortex

hartm (Sat, 29 Feb 2020 00:00:26 GMT):
I think we'll be fine. Our original conversation was probably a tiny-text-attack on the TSC...

rjones (Sat, 29 Feb 2020 00:25:43 GMT):
Has left the channel.

seanyoung (Sat, 29 Feb 2020 02:29:50 GMT):
Hello So I think it would be great to get the right people together to work on a standard set of wasm host functions. Who should we invite and what would be the best way to go about it?

shemnon (Sat, 29 Feb 2020 03:57:19 GMT):
I think we may want to check in with the smart contracts working group to get a list of interested parties.

seanyoung (Sat, 29 Feb 2020 05:22:31 GMT):
User User_3 added by seanyoung.

seanyoung (Sat, 29 Feb 2020 05:22:31 GMT):
User User_4 added by seanyoung.

seanyoung (Sat, 29 Feb 2020 05:24:24 GMT):
@shubham_aggarwal @amundson would be great to work together to work on standard wasm host interface functions in Fabric and Sawtooth Sabre. Please let us know what you think, thank you.

amundson (Sat, 29 Feb 2020 05:42:38 GMT):
seems like sabre has already defined it?

amundson (Sat, 29 Feb 2020 05:56:35 GMT):
fabric should adopt transact so we can use sabre (and other future smart contract engines) across projects.

shubham_aggarwal (Sat, 29 Feb 2020 07:17:39 GMT):
Sounds great @seanyoung. We have mapped a few fabric shim functions as basic host wasm interfaces here: https://github.com/hyperledger-labs/fabric-chaincode-wasm We can start working out on standardizing it

seanyoung (Sat, 29 Feb 2020 16:57:32 GMT):
@shubham_aggarwal great, thank you very much

seanyoung (Sat, 29 Feb 2020 16:59:03 GMT):
@amundson so sabre wasm interface has a few limitation which are problematic for Solang, and therefore for general adoption. I think has some general issues too (no "free" function for "alloc"). So either we expand/improve Sabre's wasm interface.

seanyoung (Sat, 29 Feb 2020 16:59:03 GMT):
@amundson so sabre wasm interface has a few limitation which are problematic for Solang, and therefore for general adoption. I think it has some general issues too (no "free" function for "alloc"). So either we expand/improve Sabre's wasm interface.

seanyoung (Sat, 29 Feb 2020 16:59:55 GMT):
Maybe we start with a comparison between different wasm host interfaces.

seanyoung (Sat, 29 Feb 2020 17:00:45 GMT):
A wiki page would be good for this, so everyone can comment, I think.

seanyoung (Sat, 29 Feb 2020 17:02:00 GMT):
I'm happy to start this since I have already spent time looking at them, in order to implement Solang targets.

amundson (Sat, 29 Feb 2020 18:21:09 GMT):
@seanyoung what specifically is problematic? we can fix those things, if its not just a problem understanding sabre.

seanyoung (Sun, 01 Mar 2020 01:26:38 GMT):
I'll write some notes when I have some time. Currently on holiday until HGF

seanyoung (Fri, 06 Mar 2020 04:38:40 GMT):
So I've started to write my thoughts down on what common smart contract interface should look like. This needs some reviewing and probably has lots of language bugs, but I thought I'd seek early feedback: https://github.com/seanyoung/hyperwasm

seanyoung (Fri, 06 Mar 2020 04:39:18 GMT):
@amundson see https://github.com/seanyoung/hyperwasm/blob/master/existing_interfaces.md for some feedback on the sabre smart contract interface.

seanyoung (Fri, 06 Mar 2020 04:46:01 GMT):
The plan is to flesh this repo out; make it a labs project and invite feedback via github pull requests and issues. It needs more work, there is more to add. In the mean time any feedback now would be very welcome.

seanyoung (Fri, 06 Mar 2020 04:46:25 GMT):
it also needs a name

seanyoung (Fri, 06 Mar 2020 04:46:25 GMT):
It also needs a name. I've called it hyperwasm but totally open to suggestions

shemnon (Fri, 06 Mar 2020 05:26:40 GMT):
I think the spec should provide for maximum compatibility. So there are some recommendations I think should be changed to achieve that: * Limit storage to 256 bits * Limit keys to 256 bits, and zero extend short keys.

shemnon (Fri, 06 Mar 2020 05:28:19 GMT):
For the storage values longer values can be supported, but some mapping to a 256 bit storage should be standardized so there isn't key collision. Or make a 256 bit set of APIs and a variable length stream and clients can choose which one they want (at the expense of compatability).

shemnon (Fri, 06 Mar 2020 05:31:00 GMT):
The other ones are fairly deep and we need many eyes on them.

hartm (Fri, 06 Mar 2020 17:02:42 GMT):
I'm not sure I agree with limiting keys to 256 bits. If you want to implement any kind of post-quantum cryptography, you're going to need substantially more space than that. There are a number of other cases where you're going to need more than 256 bit keys if you want to use non-basic cryptography.

hartm (Fri, 06 Mar 2020 18:36:26 GMT):
(Sorry for my dumb deleted comment earlier.)

amundson (Fri, 06 Mar 2020 18:44:44 GMT):
not sure the scope of this channel, but we also have some work going on in transact to standardize how to write smart contracts (very much a next-gen of what sawtooth SDKs have currently). will remove the merkle-tree assumption (while elegantly supporting it) so that we can get wider support for other ledgers. we expect that to be the APIs folks use for writing sabre contracts once we are done with it. minimally will be supported in anything supporting sabre, so impacts sawtooth, splinter, and grid work.

seanyoung (Fri, 06 Mar 2020 19:11:52 GMT):
Maximum compatibility is something we should aim for. Compatibility with how different ledgers approach storage, not just ethereum. Otherwise we might as well use ewasm. Different ledgers will have different limits on keys and values. So, we should use find something that works for everyone.

seanyoung (Fri, 06 Mar 2020 19:23:05 GMT):
You want to reference keys indirectly so if keys are >256 bit, then so should values. Also this makes storing strings much nicer.

seanyoung (Sat, 07 Mar 2020 16:45:11 GMT):
@hartm you actually touched on an important point. If on-chain HashMap was implemented with a simple limited bucket list and bucket chain, then a type of attack is possible where the attacker chooses keys to increase the bucket length, so that the hashmap is more like a linked list. This type of attack is usually prevented with SipHash: https://en.wikipedia.org/wiki/SipHash On public ethereum the bytecode and contract storage is stored on-chain, thus SipHash cannot be used: there is no place to store a secret. In Solidity, the HashMap is implemented using a crypto hash and no bucket list. This requires a large key space. We might want to increase this beyond 256 bits at some point. https://solidity.readthedocs.io/en/v0.6.3/types.html#mapping-types

seanyoung (Sat, 07 Mar 2020 16:45:11 GMT):
@hartm you actually touched on an important point. If on-chain HashMap was implemented with a simple limited bucket list and bucket chain, then a type of attack is possible where the attacker chooses keys to increase the bucket length (via hash collisions), so that the hashmap is more like a linked list. This type of attack is usually prevented with SipHash: https://en.wikipedia.org/wiki/SipHash On public ethereum the bytecode and contract storage is stored on-chain, thus SipHash cannot be used: there is no place to store a secret. In Solidity, the HashMap is implemented using a crypto hash and no bucket list. This requires a large key space. We might want to increase this beyond 256 bits at some point. https://solidity.readthedocs.io/en/v0.6.3/types.html#mapping-types

seanyoung (Sat, 07 Mar 2020 17:31:19 GMT):
Not sure where the merkle-tree assumption is, the smart contracts host functions use key-value pairs. It would be interesting to see what this work looks like.

knagware9 (Thu, 12 Mar 2020 16:49:40 GMT):
Has joined the channel.

GuilhermeLionzo (Mon, 16 Mar 2020 13:19:58 GMT):
Has joined the channel.

gokulalex (Fri, 20 Mar 2020 05:28:44 GMT):
Has joined the channel.

sbalikondwar (Sun, 05 Apr 2020 13:56:54 GMT):
Has joined the channel.

sbalikondwar (Sun, 05 Apr 2020 13:57:36 GMT):
hi there @seanyoung , Shivam from the mail a couple of days ago.

sbalikondwar (Sun, 05 Apr 2020 14:24:24 GMT):
currently reading on LSP protocol and paralelly trying out the Solang to wasm compilation using Solang.

sbalikondwar (Sun, 05 Apr 2020 14:24:24 GMT):
currently reading on LSP protocol and paralelly trying out the Solang to wasm compilation using Solang( also understanding solidity syntax).

seanyoung (Sun, 05 Apr 2020 14:42:54 GMT):
Hi @sbalikondwar that's great. Let me know if you have any questions.

sbalikondwar (Mon, 06 Apr 2020 14:37:04 GMT):
So I was going through the LSP specs Quite a big one with lot of minute details I am thinking to first go with rls So I am thinking about interfacing rls with Solang Perhaps we might be using Solang backend.

sbalikondwar (Mon, 06 Apr 2020 14:37:28 GMT):
Oh I forgot hi there @seanyoung

sbalikondwar (Mon, 06 Apr 2020 14:42:09 GMT):
Progressing in this order we can write rust binaries responding to LSP

seanyoung (Mon, 06 Apr 2020 15:40:18 GMT):
The LSP spec is large. However we will only need a small subset

seanyoung (Mon, 06 Apr 2020 16:17:11 GMT):
Actually, come to think of it, re-implementing all those messages again does not make any sense.

seanyoung (Mon, 06 Apr 2020 16:18:31 GMT):
Sharing code with RLS is a good idea. Possibly the LSP code on RLS can be spun out into a crate or so. There are different ways of doing this. For now we could copy that code into solang; we won't be able to get solang merged into RLS.

seanyoung (Mon, 06 Apr 2020 18:57:14 GMT):
I've spent some more time reading rust rls. The LSP messages it uses are defined in the https://crates.io/crates/lsp-types crate, so that can be used as well. RLS has a great structure so that can be used as a basis for SLS.

Dangana (Mon, 04 May 2020 00:34:40 GMT):
Has joined the channel.

sbalikondwar (Thu, 07 May 2020 21:32:55 GMT):
I did some digging in the codebase for rls and how it can help us in this process. The first thing was about rust binaries, So the server needs to respond to queries with processing the given req, for that we need a server in first place. The rls server module can be useful as it already has function support for LSP types The another requirement is of a client, Now as if we suppose there is a user IDE which will use LSP as protocol for communication Then a small program can be written which will first receive the current file, then send the required request as clicked from ide This client will just forward them through std io On the receiver side this server can use salsa lib of rust to buffer queries which our server processes The Solang backend can be wired to compile this requests from server which again are given back by server to the client. This would be integrated as a sls named dir in the current Solang codebase Sls dir will have this server, LSP types , client and other required modules Then there is need to do syntax highlighting, We can use the parser and resolver for it. I am sure parser can be hacked to give generate some special syntax tree, Alongside the current AST so that we can just travel this special syntax tree for all the syntax checks with the AST telling us symantic checks. The client current can exploit the hover, code line , etc implemented functions of rls server for hover actions from user , etc. As we know LSP is vast but I do hope the above implementation fast tracks the work and we get more time to test it alongwith features like formatting etc This is a quite high level view from my side, what are your views about it. Also sorry for the delay as you might know the classes were being conducted from home and there was quite work load in past my month when I told you I was working. But I managed to do some work in that period as you can see.

seanyoung (Mon, 11 May 2020 09:42:57 GMT):
@sbalikondwar I am thinking along the same line. So the SLS will use solang as a crate. I don't there is a need for the SLS to be a separate executable from solang itself.

seanyoung (Mon, 11 May 2020 09:44:03 GMT):
As to modifying the parser to produce the correct information we need for the language server, this is something that I am happy to do.

seanyoung (Mon, 11 May 2020 09:44:38 GMT):
As this requires some good knowledge of how Solang works.

seanyoung (Mon, 11 May 2020 10:12:17 GMT):
So RLS and Solang have compatible licenses (MIT and Apache). However we should not just copy and paste the whole thing, we should trim all the bits we don't need. I think we can refine this over time though, until the final merge.

sbalikondwar (Mon, 11 May 2020 20:11:15 GMT):
Well what I thought at first was by keeping sls as separate we can use it in many editor's, sort of a standalone utility working as server. The change doesn't require that much time so I think we can decide it at later at the time of packaging the implementation. About licensing if they are compatible then there is no issue, I agree to use only the most essential pieces.

sbalikondwar (Mon, 11 May 2020 20:11:15 GMT):
Well what I thought at first was by keeping sls as separate we can use it in many editor's, sort of a standalone utility working as server. The change doesn't require that much time so I think we can decide it later at the time of packaging the implementation. About licensing if they are compatible then there is no issue, I agree to use only the most essential pieces.

seanyoung (Thu, 14 May 2020 14:40:13 GMT):
Let's continue discussion on the language server in #solang @sbalikondwar

sbalikondwar (Thu, 14 May 2020 14:57:40 GMT):
I never knew there was a channel dedicated for Solang I thought all discussions took place here. Cool will join in.

Kazuya.N (Sat, 30 Oct 2021 12:42:58 GMT):
Has joined the channel.

rjones (Wed, 23 Mar 2022 17:27:19 GMT):

rjones (Wed, 23 Mar 2022 17:27:19 GMT):

rjones (Wed, 23 Mar 2022 17:27:19 GMT):