One of the main points people use to discredit blockchain is not just scalability but the problems with using it as a payment system. I feel like day-to-day payments will be on L2 anyways, the argument that payments will never work on blockchain because it's public and volatile makes little sense, state channels would be private enough and would even allow for fast finality, on top you use a decentralized stable coin, and you're set. Or perhaps there will be a tornado cash type Dapp which is connected to a wallet, which allows for a simple toggle "make this TX private". There are and will be a bunch of solutions, for example I still like XMR, maybe there will be a fully decentralized bridge so when I want to do really private payments I can swap and send it inside my magic wallet which does everything for me. The great thing about blockchains is that you just need to send out the signed message into the web, THAT'S IT MAN, it's so incredible and most importantly possible, there really is no way that the future won't be as bright or even brighter than we can imagine.
Kadena babena
Other urls found in this thread:
reddit.com
twitter.com
Best wallet for kda?
no one cares
>no one uses kadena
>it's so slow people are already talking about layer 2's before any real adoption
Lmao, you need to download a fucking Linux VM and start up some Gnome app called "Chainweaver". Either that or download some 3rd party wallet called "Zelcore" that's so shifty, Rajesh from Bangalore would blush recommending it.
where is Emily? I want to tongue her anus in Minecraft
On a related note, isn't KDA a testnet token that will get converted 5:1 after main launch? why buy it now?
WARNING: This is a scam thread where shills are paid to post.
>tfw people pay me to post underage anime girls
life is good
>where is Emily?
when heads go down, shit goes down
basedo
xwallet is fine
The post was just an excuse to post anime, imagine taking it seriously what kinda brainlet are you lmao.
Kda is the only coin capable of being used for global payment on L1, the shitpost is just about privacy.
>frogposting on a sunday..
huh???
>I've read that the block time per chain is 30s. Does this mean that transaction finality is 30s? So, if I make a swap on a dex for example, I will need to wait at least 30s for my transaction to be mined and around 3x that = 90s for my transaction to be confirmed/finalized?
This is a safe assumption. In practice, if you see a fork of depth > 3, it's either a network partition or a 51% attack. For exchanges, we often recommend 3-6 minutes for their settlement integrations as the extra difference doesn't really matter much to the end-user. We tried to do the probability math for what the odds of finality are at depths 2, 3, etc but the probabilities aren't independent and we don't believe a closed-form solution exists.
There were parts of chainweb where we could treat the probabilities as independent, specifically the odds of finality for depth 3 vs 4, and the results were so hysterically good that we were worried that people wouldn't believe them... so much so that we went down the simulatory approach as Gauntlet's first client and Tarun built a massive agent-based simulator to verify security a second time.
>How does scaling a dApp across the 20 chains work? For example, anedak swap is currently live on chain 3. If they are to scale across to all 20 chains to increase throughput, would it mean that there will in fact be 20 different liquidity pools per trading pair, one on each chain?
There are a number of ways to go about it. But, we like to dogfood our tech, so the very first dapp on our platform is literally KDA (see: coin contract) and it's fully + autonomously scaled across all 20 chains.
When it comes to DEXs, this is still an active area of research... mostly because Kadena's the first (and still to my knowledge only) for real, sharded network. Here sharded = partitioned, not sharded = DAG, which is why how to scale a dapp on-chain is even open as an area of research.
One way to do it is to have every pair on every chain, and figure out how to shuffle liquidity around as needed. Another option is to specialize chains to certain pairs. Another option is to have the dapp's core token itself float (so KDX or ADK, but there's a price for each chain's contract's token) and list the (chain_n,chain_m) pairs on the dex itself (e.g. KDX_0/KDX_1). I personally prefer the specialization of pairs on a per-chain basis, but I could easily be wrong, and I suspect there's some very interesting gold to be had at the bottom of the floating-code-token approach.
We have some new features in progress that will make multichain-dexs easier to code for end-users. Specifically nested co-routines, as then a dex can compose a cross-chain tx with some follow-on action in a single sig (e.g. remove liquidity from pool X and chain N, cross-chain transfer that liquidity over to chain M, add that liquidity to pool Y on chain M).
>which is why how to scale a dapp on-chain is even open as an area of research.
For anyone watching, the NEAR devs have confirmed that contracts/accounts aren't shard-aware. They are tracking down the algo that determines shard-locality for me. Jury's still out on how NEAR exec actually works and what (if anything) it does to address ahmdal's. I was talking with another researcher, and we think a sufficiently intelligent tx routing + shard allocator could maybe provide a UX like NEARs (accounts/contracts don't have to care about which shard they are on) and exceed the best case 20x scaling-factor bound (ahmdal's law).
That said, such an advanced engine would be a serious innovation in CS let alone crypto. To make correct decisions, the engine would need to be fully aware of: the entire state of the network, historical transactions, the txs "meaning" (not just the code), and probably a number of other factors I can't think of. It need to make decisions in realtime, so it'd need to be fully updated with every shard's latest contents, and every so often it'd need to be able to re-org the shard allocations according to usage patterns. While I can barely fathom an engine that could support 10 shards (shards = sandboxed exec envs, like chains in chainweb or cores in a CPU) I can't fathom one that can handle 1000 if only because it'll need to process 1000 shard-blocks to stay up to date, which modern hardware can't do. I say "barely fathom" because, as someone who has worked on formal verification for pact, getting a computer to understand the "meaning" of a turing incomplete language is barely possible... and NEAR's WASM exec env isn't turing incomplete... but it is gas limited so maybe the engine could run the code and track what it does vs understanding the raw code. Still though, major undertaking to build a schedule like this.
Oh, and the engine would need to be deterministic (or centralized) which probably removes any probabilistic approaches...
none of you are honored to receive a reply from emily, and it shows
meds agg
where
>We have some new features in progress that will make multichain-dexs easier to code for end-users. Specifically nested co-routines, as then a dex can compose a cross-chain tx with some follow-on action in a single sig
Is Kadena what Cardano would be if Charles knew how to program?
>Is Kadena what Cardano
yes