| 7 May 2018 |
 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 |
 @gitter_gcolvin:matrix.org | 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 |
| @gitter_gcolvin:matrix.org | 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 |
| @gitter_gcolvin:matrix.org | 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 |
| @gitter_gcolvin:matrix.org | (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 |
| @gitter_gcolvin:matrix.org | (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 |
| @gitter_gcolvin:matrix.org | (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 |
| @gitter_gcolvin:matrix.org | 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 |
| @gitter_gcolvin:matrix.org | (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 |
| @gitter_gcolvin:matrix.org | | 00:10:41 |
| @gitter_gcolvin:matrix.org | 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 |
| @gitter_gcolvin:matrix.org | | 00:14:31 |
| @gitter_gcolvin:matrix.org | Oh, a good starting point for a gas formula that has y=0 when x=0 and asymptotes on 1 is | 00:14:31 |
| @gitter_gcolvin:matrix.org | (edited) Oh, a good starting point for a gas formula that has y=0 when x=0 and asymptotes on 1 is => a good starting point for a gas formula that has y=0 when x=0 and asymptotes on 1 | 00:14:49 |
| @gitter_gcolvin:matrix.org | https://www.extremetech.com/wp-content/uploads/2014/08/latency.png | 04:56:42 |
| @gitter_gcolvin:matrix.org | A few years old, but not too different. No smooth function is right here. The YP is linear to 724B, which fits no particular hardware boundary, then goes quadratic, which maybe fits through the layers of cache. But it then takes an exponential or steeper to catch the 50:1 increase to RAM. But it's not the cost of allocation that really increases so much as the latency, and that goes up (in the EVM) by the address loaded or stored from. Since the cost for these is set at very-low we can assume that memory access is not intended to be outside of cache. | 05:14:11 |
| @gitter_gcolvin:matrix.org | (edited) ... we can assume that memory access is not intended to be outside of cache. => ... we might assume that memory access is not intended to be outside of cache. | 05:17:58 |
| @gitter_gcolvin:matrix.org | Regardless, we'd like for the cost of memory allocation to approach a brick wall at whatever the maximum reasonable memory allowed to a contract is. | 05:19:14 |
| 11 May 2018 |
| @gitter_gcolvin:matrix.org | And if I haven’t prattled on enough (and I hope you are reading this on Gitter, not on Riot, where my every edit is preserved) I’ll note that y = 2 ^ x gives a very similar curve. | 03:44:07 |
| @gitter_gcolvin:matrix.org | Summary of all the above being
- memory management might too complex for the VM runtime
- the gas function for memory should and can be simple
| 03:44:18 |
| 19 May 2018 |
|  @rinor.hoxha:matrix.org joined the room. | 10:03:25 |
| 26 Jun 2018 |
| @gitter_gcolvin:matrix.org | And of course subtract 1 from these if you to start at zero. At some point this needs to turn into an EIP you can pick up i you want. Currently Ethereum puts such a low limit on memory (less than 32K) that it’s not a DoS vulnerability—you can't get out of the megabytes of cache. | 16:46:03 |
| @gitter_gcolvin:matrix.org | What I’m up to is slowly critiquing my way through this beautiful work as a means of understanding it. I’m a volunteer Etherian at this point, so it’s very slow. | 16:51:55 |
| 2 Jul 2018 |
|  pox joined the room. | 01:11:47 |
| 12 Jul 2018 |
| @gitter_gcolvin:matrix.org | An observation and a question. First, I still worry that the time for memory operations may be non-deterministic, and that a deterministic allocator will waste either time or space. I’d prefer to just not have a free operator. But it’s possible to write a determistic allocator, so that might suffice. | 13:25:14 |
| @gitter_gcolvin:matrix.org | Next, some op results have more bits than their operands. But that is not the semantics of LLVM integers. This could force extra nmemory allocation and a mod operation when the extra bits are unwanted. | 13:31:57 |
| 21 Aug 2018 |
|  @gitter_bredamatt:matrix.org joined the room. | 21:56:48 |
| @gitter_bredamatt:matrix.org | Hi, I am highly interested in learning more about IELE and VMs for blockchain technology. I am a fast learner, and currently enrolled in a 4 year PhD program in Informatics. However, I have little experience with VMs. My work is primarily in formal modelling, which also is maths-heavy and semantics oriented. I wanted to ask if there are any good resources available to read so I can up my understanding of VMs before I start looking into writing Smart contracts for the Cardano / Ethereum platform. Best wishes, M | 21:56:57 |
| 24 Aug 2018 |
|  @gitter_sebastiengllmt:matrix.org joined the room. | 07:16:27 |
| @gitter_sebastiengllmt:matrix.org | I don't understand why in https://github.com/runtimeverification/iele-semantics/blob/master/iele-gas.md
he size of the result register REG for an arithmetic operation log2 is set as the constant 2
rule #memory [ REG = log2 W ] => #registerDelta(REG, 2) | 07:16:32 |
