We could have a SyncReadableKeyValueStore and SyncWritableKeyValueStore

pub trait SyncWritableKeyValueStore: WithError {
    /// The maximal size of values that can be stored.
    const MAX_VALUE_SIZE: usize;

    /// Writes the `batch` in the database.
    fn write_batch(&self, batch: Batch) -> Result<(), Self::Error>;

    /// Clears any journal entry that may remain.
    /// The journal is located at the `root_key`.
    fn clear_journal(&self) -> Result<(), Self::Error>;
}

These synchronous traits could be implemented for the KeyValueStore of the linera-sdk. This would be a gain since the asyncness of the calls to the views in the smart contract is artificial.

We would need to also have a SyncContext trait implemented from a SyncKeyValueStore. The real problem comes from the code in src/views directory of linera-views which is relatively significant (10000 lines).

Rewriting the code by hand would probably be a mistake, and instead, a better strategy is likely to use procedural macros to map the async views into sync views. The change is somewhat straightforward: We simply have to drop the async and await entries in the code.

Further ideas are open:

• It is also possible that the right solution in the end is to add Async as prefix for the existing views and stores and the sync ones would not have Sync as a prefix.
• If the SyncKeyValueStore ends up being used only by the linera-sdk, maybe having the API not throwing errors could be a good idea. That would end up cleaning up a lot of unwrap() statements in the example code.