| 22 Apr 2018 |
|  @gcolvin:matrix.org removed their display name Greg Colvin. | 17:58:40 |
| @gcolvin:matrix.org | 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 |
|  @gitter_gcolvin:matrix.org joined the room. | 18:38:25 |
| @gitter_gcolvin:matrix.org | 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 |
 @gitter_grosu:matrix.org | 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 |
| @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 |
