--- tags: tezos, soru --- # About Pistachio Marigold values developer and user experiences when it comes to Tezos ecosystem. We are very excited about the upcoming SORU announcement and have started our pilot programme to develop kernels on top of SORU. Here we would like to share our thoughts. # Developer experience ## Software development kit (SDK) SORU has a well-documented Rust SDK. Although there are rough edges in APIs, we have listed them as issue tickets in Pistachio repository and we are progressively proposing the improvements and implementing them. ## Observability SORU kernels at the moment must be run on top of SORU nodes which interpret the kernels. However, kernel execution mostly remain silent. There is a lack of venue to observe the progress of the kernel execution, logging and error reporting. From the point of view of operation and engineering, this poses a major challenge in tracking and identifying potential problems. We would like to propose the following improvements: - Allow separate logging for kernels. Currently logging kernel debug message does not have any effect. Even if it is possible, it would be drown out by the log lines from processes interacting with Tezos chain. - Better tracing. Rust, via tracing.rs, and many other languages have good support for logging. We propose to looking into possible venue to make tracing to be first possible and then cheap. This would make testing and monitoring very much easier. - Error reporting. Panics in kernel, such as by executing the unreachable instruction, is silent. We propose to let the nodes report the panics and further explore ways to extract panic messages. ## Documentation During this endeavour, we also have noted down issues around the documentation of SORU. We are concerned that there is no complete specification of the WASM environment. We have identified a few areas that a kernel developer would have questions for while the exisiting documentation has insufficient answers. - WASM interface - While we can infer the host functions that WASM kernels should link against, it is not clear about the semantics of those functions. There is a lack of connection between the Tezos SORU _modus operandi_ and that of the kernel. For instace, it was not clear to the developers that they need to program their kernel to process all the messages in the inbox in a loop until the box is empty, because the kernel entry is only invoked once for one inbox at each level. - SORU filesystem hierarchy. - There are "magical" storage paths that the kernel can read from or write input. Some are more useful but left unexplained. They include, for instance, kernel upgrades and retro-inspection of outbox messages. We would like to propose to gradually document those special storage keys to explain their use and semantics. ## Developer productivity Pistachio at Marigold also serves as a monitor for developer productivity in the story of providing a smooth developer experience and higher productivity. In this programme, we record new knowledge gained from this pilot project in order to provide useful guides for our prospective SORU kernel developers. We will also provide insight to SORU project about possible areas for improvement, proposal for better toolchains and more. Stay tuned for more discussion on #marigold-kernel for annoucement and disucssion. We thank you for your attention!