The host-side BEEFY spec (the BEEFY finality gadget, and payload structures) is already described in the finality section of the protocol spec. These specifications justifiably do not include any information on how the light client fetches and verifies the BEEFY payloads.
We should have an implementer's guide which provides technical details of light client interacting with the BEEFY protocol. We can instantiate the light client as a smart contract , arguably one of the most resource constrained environments for running a light client. This closely mirrors the snowbridge implementation. Implementer's can of course modify the interactions/components according to their setting (example generating randomness which is more nuanced on light client running on-chain than off-chain).
The host-side BEEFY spec (the BEEFY finality gadget, and payload structures) is already described in the finality section of the protocol spec. These specifications justifiably do not include any information on how the light client fetches and verifies the BEEFY payloads.
We should have an implementer's guide which provides technical details of light client interacting with the BEEFY protocol. We can instantiate the light client as a smart contract , arguably one of the most resource constrained environments for running a light client. This closely mirrors the snowbridge implementation. Implementer's can of course modify the interactions/components according to their setting (example generating randomness which is more nuanced on light client running on-chain than off-chain).