# Xuejie Xiao - A Journey Optimizing CKB Smart Contract (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/26683753) **Source**:: #from/readwise **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Xuejie Xiao]] **Full Title**:: A Journey Optimizing CKB Smart Contract **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [readwise.io](https://readwise.io/reader/document_raw_content/48251229) **Host**:: [[readwise.io]] **Highlighted**:: [[2023-04-21]] **Created**:: [[2023-04-22]] ## Highlights - If more performance boost is really necessary, say you need 5x or 10x of the current performance, the only viable path IMHO, would be a major rewrite, either from the algorithmpoint of view, or froman architecture point of view. ([View Highlight](https://read.readwise.io/read/01gyhee0g1c2gvw1wq1g6c9vq8)) ^512574497 - If you have looked at the MMR C verifier code carefully, you might noticed that instead of a vector of proof items, the C verifier leverages a serialized buffer of proof data, then reads out commands from the proof data much like a small interpreter. This is due to the observation that MMR proof verification is nothing but a series of hash functions applied to designated values at certain order. ([View Highlight](https://read.readwise.io/read/01gyhee8x9827nhp4f8sdnxc6a)) ^512574503 - Somewhat ~470000 cycles are wasted initialization blake2b hasher, while in fact we are only using one type of blake2b hasher in the verifier. So the idea is: what if we can make the blake2b hasher constant, so all we need to do is initializing it once, not initializing it again and again? ([View Highlight](https://read.readwise.io/read/01gyheen4f74b6v0h4gdrxcwrk)) ^512574508