Since the baseapp itself is written in Rust, we can compile the whole chain daemon into the wasi program, and upgrade the binary on the fly via governance. Since the chain-program, mentioned in the PLAN.md in the baseapp crate, can take filesystem component and expose ABCI 2.0 methods, it is already somewhat capable of modeling the full chain - in this case, we are effectively using a "kernel" chain-program as our baseapp where every transaction goes through it. However, I am not sure if the filesystem api is enough to support the kvstore too. We have intentionally removed the get/set style api to be exposed to the wasi programs and replaced them with filesystem abstraction, but the actual baseapp needs to access the underlying rocksdb. One idea is that, we designate the special path(from the minimal harness that doesn't get upgraded, like base-baseapp or bootloader) that acts as the proxy to the physical rocksdb. When the kernel chain-program runs rocksdb::DB::open_default(path), the bootloader routes it to the underlying rocksdb connection, and the rest of the DX from the kernel side remains same.
@claude Write a coherent proposal out of this one. Do not dive deep into the implementation, but focus on the concept and the idea. Do not write in the style of bulletpoints.
Since the baseapp itself is written in Rust, we can compile the whole chain daemon into the wasi program, and upgrade the binary on the fly via governance. Since the chain-program, mentioned in the PLAN.md in the baseapp crate, can take filesystem component and expose ABCI 2.0 methods, it is already somewhat capable of modeling the full chain - in this case, we are effectively using a "kernel" chain-program as our baseapp where every transaction goes through it. However, I am not sure if the filesystem api is enough to support the kvstore too. We have intentionally removed the get/set style api to be exposed to the wasi programs and replaced them with filesystem abstraction, but the actual baseapp needs to access the underlying rocksdb. One idea is that, we designate the special path(from the minimal harness that doesn't get upgraded, like base-baseapp or bootloader) that acts as the proxy to the physical rocksdb. When the kernel chain-program runs rocksdb::DB::open_default(path), the bootloader routes it to the underlying rocksdb connection, and the rest of the DX from the kernel side remains same.
@claude Write a coherent proposal out of this one. Do not dive deep into the implementation, but focus on the concept and the idea. Do not write in the style of bulletpoints.