| 16 Mar 2018 |
 matekdk | Grigore: Cool - is there a specific person I should contact in that regard ? For possible biz-inquiries also - in regards to needed tweaks to iele. | 13:25:40 |
 Grigore | matekdk: you can always contact dwight.guth, @brandon.moore, @theo.kasampalis and myself (see https://runtimeverification.com/team/). We'd like to know what you plan to do with it. | 15:09:08 |
| matekdk | Grigore: Thanx - you guys will receive en email from me later. | 18:33:35 |
| 27 Mar 2018 |
|  @zhanla0:matrix.org joined the room. | 01:47:10 |
| @zhanla0:matrix.org | will a c++ blockchain work with iele? | 02:04:52 |
| @zhanla0:matrix.org | iele seems like a great project. I really am glad to see the industry moving away from ethereum dependence such as EVM. | 02:06:21 |
 dwight.guth | Iele has an open source inter process communication api for invoking the vm to execute a transaction, so code in any language can be used to interface with it if it follows that interface. The code is also under a very permissive open source license, so nothing is stopping you from implementing a iele vm in c++ either. | 04:06:30 |
| @zhanla0:matrix.org | great thanks! | 04:28:41 |
| 14 Apr 2018 |
|  hysnabi joined the room. | 12:17:42 |
| 22 Apr 2018 |
|  Greg Colvin joined the room. | 17:29:22 |
| Greg Colvin changed their display name from gcolvin to Greg Colvin. | 17:53:32 |
| Greg Colvin set a profile picture. | 17:56:53 |
| Greg Colvin removed their display name Greg Colvin. | 17:58:40 |
| Greg Colvin | 18:00:06 |
| 27 Apr 2018 |
|  jurajselep | simplestaking.com changed their display name from jurajselep to jurajselep(simplestaking.com). | 15:23:16 |
| 7 May 2018 |
|  Greg Colvin (Gitter) joined the room. | 18:38:25 |
| Greg Colvin (Gitter) | Some performance concerns.
- First, the arbitrary-precision arithmetic would seem to make it difficult to efficiently implement registers of fixed size with twos-complement wrap-around.
- Next, the flat-then-quadratic memory cost function doesn't work that well for the EVM, adding complexity without adding realism. Actual memory takes a few approximately exponential jumps through fast cache to RAM, then is flat again until it hits a wall when memory runs out. Perhaps a well-tuned function of the form y=a+b/(c+x) could give a flat start and a steep rise toward an asymptote.
- Worse, the operations for resizing memory take a fixed amount of gas per memory delta, but in real memory-management runtimes the time taken varies, and is a vulnerability. And memory management runtimes add unfortunate complexity to the VM.
| 18:38:32 |
 Grigore Rosu (Gitter) | Hi @gcolvin , nice to see you here. Thanks for your comments. We'll get back to you with some questions to see what your thoughts are about this.
Note that our main objective here was really to make formal verification of smart contracts easier. We verified a few on the EVM (https://github.com/runtimeverification/verified-smart-contracts) and we designed IELE with that experience in mind.
Like anything else, it is an experiment. We tried to come from the mathematical side, to have things clean there, and then worry about the (admittedly important) low-level details afterwards; that is, now :). | 18:54:58 |
| dwight.guth | Hi. I was one of the developers behind IELE. Thanks for your suggestions. We are definitely aware that the gas model is a work in progress, so thank you for your offered expertise. I was wondering if you could answer a few questions to help me understand your feedback better.
First, you mention a function of the form y=a+b/(c+x) for memory usage. Can you tell me how you came up with that equation, what each of the constants might signify, and approximately the order of magnitude you had in mind for the constants?
Second, you mention the gas cost for resizing memory. Can you explain in a little bit more detail what the vulnerability you mention is and how you would personally think to alter the gas model of IELE to address these concerns. | 19:04:34 |
| Greg Colvin (Gitter) | The function is just from playing around in a graphing calculator. You can adjust the constants to approximately fit the shape of the function to shape of actual memory performance, and the brick wall of the current physical limit on RAM. Other formulas might do, including some form of exponential. But a quadratic doesn't rise fast enough. | 23:53:32 |
| Greg Colvin (Gitter) | In general, memory management is difficult. The only ones I know of that operate in constant time allocate and free objects of fixed size (typically powers of two) with no attempt to coalesce objects, but depending on the pattern of access these can waste an arbitrary amount of memory. (Your variable-sized integers would need to be allocated inside one of these, and would need to be copied and reallocated whenever they filled on up. When that happened would depend on the implementation.) | 23:58:24 |
| 8 May 2018 |
| Greg Colvin (Gitter) | Most memory managers attempt to balance memory usage and speed of allocation with a bag of tricks, none of which is guaranteed to work. The attack is to find way to cause the memory manager to use too much RAM and/or too much time relative to the gas spent. | 00:00:34 |
| Greg Colvin (Gitter) | (edited) Most memory managers attempt to balance memory usage and speed of allocation with a bag of tricks, none of which is guaranteed to work. The attack is to find way to cause the memory manager to use too much RAM and/or too much time relative to the gas spent. => In general, memory management is difficult. The only ones I know of that operate in constant time allocate and free objects of fixed size (typically powers of two) with no attempt to coalesce objects, deallocated objects are simply placed on the free for their size. Depending on the pattern of access this kind of allocator can waste an arbitrary amount of memory. IELEs variable-sized integers would need to be allocated inside one of these, and would need to be copied and reallocated whenever they filled on up. When that happened would depend on the implementation. | 00:02:18 |
| Greg Colvin (Gitter) | (edited) In general, memory management is difficult. The only ones I know of that operate in constant time allocate and free objects of fixed size (typically powers of two) with no attempt to coalesce objects, deallocated objects are simply placed on the free for their size. Depending on the pattern of access this kind of allocator can waste an arbitrary amount of memory. IELEs variable-sized integers would need to be allocated inside one of these, and would need to be copied and reallocated whenever they filled on up. When that happened would depend on the implementation. => Most memory managers attempt to balance memory usage and speed of allocation with a bag of tricks, none of which is guaranteed to work. The attack is to find a way to cause the memory manager to use too much RAM and/or too much time relative to the gas spent. | 00:03:12 |
| Greg Colvin (Gitter) | (edited) Most memory managers attempt to balance memory usage and speed of allocation with a bag of tricks, none of which is guaranteed to work. The attack is to find a way to cause the memory manager to use too much RAM and/or too much time relative to the gas spent. => In general, memory management is difficult. The only ones I know of that operate in constant time allocate and free objects of fixed size (typically powers of two) with no attempt to coalesce objects; deallocated objects are simply placed on the free list for their size. Depending on the pattern of access this kind of allocator can waste an arbitrary amount of memory. IELEs variable-sized integers would need to be allocated inside one of these, and would need to be copied and reallocated whenever they filled on up. When that happened would depend on the implementation. | 00:05:16 |
| Greg Colvin (Gitter) | Most memory managers attempt to balance memory usage and speed of allocation with a bag of tricks, none of which is guaranteed to work. The attack is to find a way to cause the memory manager to use too much RAM and/or too much time relative to the gas spent. | 00:05:44 |
| Greg Colvin (Gitter) | (edited) ... The attack is to find a way to cause the memory manager to use too much RAM and/or too much time relative to the gas spent. => ... The attacks are to find a way to cause the memory manager to use too much RAM and/or too much time relative to the gas spent. The details of an attack vary with the (often quite complex) details of the runtime. | 00:06:55 |
| Greg Colvin (Gitter) | | 00:10:41 |
| Greg Colvin (Gitter) | Most memory managers attempt to balance memory usage and speed of allocation with a bag of tricks, none of which is guaranteed to work. The attacks are to find a way to cause the memory manager to use too much RAM and/or too much time relative to the gas spent. The details of an attack vary with the (often quite complex) details of the runtime. | 00:13:17 |
| Greg Colvin (Gitter) | | 00:14:31 |
