# Charon architecture feedback ### By: Raul Jordan The architecture for Charon is pretty solid so far, but there are a few important considerations to note. The core workflow of a Charon validator's duty can be summarized as: 1. Schedule duties 2. Figure out what to sign 3. Sign 4. Share with others 5. Reach consensus on the signed data 6. Aggregate 7. Broadcast I think having an ordered section with the titles above could add more clarity to the architecture, as the chart below can be tricky to follow at first sight due to the two-dimensional presentation. Having the architecture explained in these 7 categories could make the design more concise and easy to follow. ![](https://i.imgur.com/fi9PlMr.png) Another recommendation is to use [keywords recommended for RFC specs](https://datatracker.ietf.org/doc/html/rfc2119) as it adds clarity to the spec about what is and is not allowed by the different components. This will help clarify how to implement the same workflow in case there are multiple language implementations of Charon. # Key Consideration Charon is an extension of a normal validator's duty, and a normal validator's duty is pretty strictly defined in the Ethereum consensus spec. In the period of a single slot, a validator should perform attesting, signing, broadcasting, and/or proposing at specific intervals of the slot. As Charon adds in more details such as consensus and aggregation of sig shares, it is important to clarify at what intervals of a slot these should happen. That is, at 1/3rd of a slot, do X, at 1/2 of a slot, do Y, etc. These are defined in the consensus spec [here](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md), and it is worth investigating optimal spread of responsibilities under some conservative estimates. There are some attacks on Ethereum PoS that rely on timings of released messages in consensus that could be relevant to Charon as well.