[Editorial] Terminology section or Glossary

[findthomas]

About you

Please include your name so your contribution can be publicly acknowledged in the final publication.

Name:
Organization/Company:

About your review

Document: EEA DLT Interoperability Specification
Section: Use the URL to identify the right section of the document.

Comments/Suggestions/Feedback

Would it make sense to have a Terminology or Glossary section?

Terms like "event attestation" could be defined in one or two sentences.

Same with "state attestation".

[chaals]

I tend to suggest defining terminology inline. Using Respec to generate specs, that gives us an index of all the terms we use, instead of a bunch of pages of definitions.

That said, I don't really care - this is an editorial question so the "right" answer is probably "what the group prefers".

[Aa-Ja]

I would lean towards including a Terminology/Glossary section. While the index of terms would be a useful tool in itself, the Terminology/Glossary section would serve different purposes.

I see the Terminology/Glossary section as an opportunity to ensure uniformity and consistently when it comes to the use of terms in future written communications.

Can we create a Terminology/Glossary section based on the terms developed using Respec? Or would this just lead to pages of definitions?

[anaisofranc]

Many terminologies and taxonomies have already been published. For example https://www.iso.org/obp/ui/en/#iso:std:iso:22739:ed-2:v1:en The group is aligned with the commonly used terms. We will review the definitions of specific terms mentioned in the issue (event attestation and state attestation) to ensure completeness.

[anaisofranc]

Event-attestation is described in section 3.4

"3.4 Event-based messaging mechanism In an EVM-based environment, event attestation is a process that utilizes the block header's receipt root to prove that events occurred within that particular block. This receipt root is a cryptographic commitment to the list of transaction receipts, which in turn contain the smart contract event logs. The event data would typically contain information to trigger an action on the destination network."

And is further developed in section "3.4.3 Event Attestation".

[anaisofranc]

The following has been added to the beginning of "3.5 State-based messaging mechanism".

"State attestation refers to the process of verifying and certifying the correctness of a network's state at a specific point in time. The primary goal is to ensure that the data presented is accurate and has not been tampered with."