RFC: trits-t1b1 encoding
#14
Conversation
|
|
||
| # Motivation | ||
|
|
||
| This encoding of sequences of balanced trits is necessary for the `Curl` hash function and therefore still necessary to allow for the Bee framework to interoperate with the current IOTA mainnet. |
There was a problem hiding this comment.
Curl can be implemented using a more efficient encoding (64 trits per two 64-bit words). This way memory footprint can be reduced by a factor of 4. When pointer arithmetic is used to access words of Curl state (instead of LUT) then the memory footprint reduces additionally be a factor of 4/3. All in all, optimizing of Curl is worth investigating.
So, it's not a very convincing argument that "balanced trits is necessary for the Curl". Maybe we should talk about Curl-compliant encoding?
t1b1 however is the simplest encoding that could be very useful for tests, to compare invariants when other encodings are used to perform the same trits transformation.
There was a problem hiding this comment.
Not if we actually do a difference between Curl and PCurl. Per se Curl is the one operating on T1B1 while PCurl accepts different encodings. It is briefly mentioned in the base RFC here https://github.com/iotaledger/bee-rfcs/pull/10/files#diff-b075c83057cb59013a66d6ee87aa3986R31.
There was a problem hiding this comment.
yea, I know of BCT-Curl. There is already a Rust port of it btw. But can we use it as a full replacement for Standard-Curl? Or putting this question differently: Is there really no other usecase for T1B1 other than tests, debugging, ....
There was a problem hiding this comment.
I think for single hashing Curl is faster than PCurl because of all the overhead it has. Also, almost all prototyping is done with T1B1.
Rendered