A simple structure for the layers of the project

[ggonzalez94]

We said it is important to distinguish what is a core protocol concern(e.g. PublicationFeed, CheckPointTracker and interfaces) vs extensions or application concerns(e.g. ERC20Bridge or the specific incentive mechanism for provers). This doc summarizes our current folder structure and here are also some open questions:

Questions

If protocol is the folder for core contracts of the stack:

• Should we move signal inside protocol? I do consider L1<>L2 messaging and bridging ETH a core concern of the protocol
• Is it worth dividing the protocol folder into L1, L2, shared similar to the current taiko-mono repo or are we better of with the current structure?

[LeoPatOZ]

• Should we move signal inside protocol? I do consider L1<>L2 messaging and bridging ETH a core concern of the protocol

I think so yes, considering it is a core part of the protocol (given the publish function will call the signal service)

• Is it worth dividing the protocol folder into L1, L2, shared similar to the current taiko-mono repo or are we better of with the current structure?

I also like this separation :)

[LeoPatOZ]

For now though do we need nesting of protocol/taiko_alethia ?

Also are we merging this PR (as currently the fomrating in the markdown document doesnt work:

[ggonzalez94]

Lol not sure what happened with formatting, but should be fixed now.
Regarding the other decisions I'll wait for others to weigh in before doing the changes.

For now though do we need nesting of protocol/taiko_alethia

Would you put the folder outside protocol?

[LeoPatOZ]

Lol not sure what happened with formatting, but should be fixed now. Regarding the other decisions I'll wait for others to weigh in before doing the changes.

For now though do we need nesting of protocol/taiko_alethia

Would you put the folder outside protocol?

I was thinking we could directly have

protocol/L1
protocol/L2
protocol/shared

[dantaik]

Note that Taiko’s L2/shared code is built with evm_version = "shanghai", while the L1 code uses evm_version = "cancun". I’m not suggesting we must follow the same approach for the new protocol, but it’s possible that L2 and L1 may still require different EVM versions.

[dantaik]

Feel free to avoid using taiko or alethia in the codebase unless the core protocol is very generalized, with Taiko Alethia functioning purely as a module built on top of it and serving as an example.

For now though do we need nesting of protocol/taiko_alethia ?

Also are we merging this PR (as currently the fomrating in the markdown document doesnt work:

[ernestognw]

Should we move signal inside protocol? I do consider L1<>L2 messaging and bridging ETH a core concern of the protocol

Agree with this, ISignalService and SignalService should be inside of protocol. This is the current state in #45

Is it worth dividing the protocol folder into L1, L2, shared similar to the current taiko-mono repo or are we better of with the current structure?

Some contracts will be deployed on both sides, so I think different folders is not helpful information. Imo it's a documentation issue, the user should have concrete steps to deploy its rollup, where we can be more specific about L1/L2