Log#Write Capability about cap9 HOT 5 CLOSED

I've chosen this as the capability to implement next, as it doesn't involve any additional mechanisms except those required for write. By implementing this we can simply test how general the system is.

from cap9.

Each log item can have 0-4 topics. We can use these topics to form a hierarchy of sorts. A log capability can have the following formats:

• 0: The procedure can write to any combination of 0-4 topics.
• 1 [firstTopic]: The procedure must have at least one topic, and the first topic must be "firstTopic".
• 2 [firstTopic. secondTopic]: The procedure must have at least two topics, the first topic must be "firstTopic". and the second topic must be "secondTopic"
• 3: as above but with 3 topics
• 4 [firstTopic, secondTopic, thirdTopic, fourthTopic]: Must have exactly 4 topics exactly as specified.

The format of the capability is currently that the first 32 bytes are the number of topics, and the next 0-4 32-byte values are the topics themselves. This means the capability can be 1, 2, 3, 4, or 5 32-byte values long.

0x0: number of topics, `nTopics` (32 bytes)
0x20: first topic
0x40: second topic
0x60: third topic
0x80: fourth topic

from cap9.

Sounds good.

I imagine we could make the topics smaller (8 bytes each), fit the cap in a single key (32 bytes) and simply use 0x0 as a "empty" marker. This would be more complicated though.

from cap9.

Yes, but then you are also dramatically limiting the use of topics, as topics on the EVM are 32-byte. Probably not worth the small packing gains.

Actually there are a few other instances where we could definitely reduce number sizes where we are currently just using 32-byte words, which I've done for simplicity.

from cap9.

This is currently implemented in #44.

from cap9.