Đ8

I just watched this video and it made me think about investing in #kaspa, he talks about in order to be successful you got to think contrarian (the opposite of what every one else is doing) and have conviction when every one else doesn't have the patience, some have left $kas because they didn't get 100x after holding for a year, some are sticking to the usual cryptos $eth, $sol and $btc , few thousand of us are thinking contrary because we see the value and know what's coming youtu.be/_ZJpU43NA0c?is…

twitter.com/i/spaces/1oJMv…

prologue Taking my dr.’s (Sompolinsky) advice to rest a bit and have fun after Toccata’s release, I started experimenting with argent: a small high-level DSL for multi-contract covenant apps that produces silverscript code. Please don’t laugh at this definition of “rest” ;) Releasing heavy core consensus upgrades carries a massive burden of mainnet responsibility. Playing with language compilers and application structure is exploratory work. So yes, for some ppl, it might genuinely feel like resting. --- About three months ago, during the development of Toccata and silverscript, Ori (@someone235) threw a quick sentence at me: “You can implement a mechanism similar to MAST using ICC.” (Stay with us if you want to understand what MAST is and why Ori was only partially right.) Around that time, I started playing with complex scripts over silverscript and mostly tried to understand what a complex contract system over the new Kaspa script engine/silverscript could look like (or if one could be built at all). One thing led to another and I started trying to develop a chess game over silverscript. “okay codex, let’s start developing chess, let’s start with a chess game with basic movement rules, no complications. An array of 64 cells representing the board, public keys for black/white, turn, movement. The bare minimum that is still sufficiently complex.” Of course, the first attempt didn’t go so well. As is fitting for a compiler in its early days, I quickly reached a state where I was the first one walking through certain code paths. This triggered a burst of contributions to silverscript itself and/or finding temporary workarounds. The second attempt got stuck on the boundaries of the script itself. It turns out that implementing all the game rules for every possible piece plus scan loops statically unrolled to 64 iterations is, how should I put it, not really workable and tends to blow up. I came to the conclusion that the logic needed to be shattered into different contracts, meaning different scripts. But how do you do that within the boundaries of a game? And what if I want to implement a decentralized chess league with players and scores that persist and update over time? (By the way, chess is a complex and interesting test case for development, but don’t mistakenly think for a second that this discussion is limited to or aimed at games.) >>