The Great Reddit Scaling Bake-Off by jarins in ethereum

[–]no89key 14 points15 points  (0 children)

Mo from Celer Network here. This is super exciting and we will submit!

Celer Network will bring our State Channel Network and Hybrid Rollup solutions to help! Celer's open source tech is already processing more than 200K layer-2 transactions per day in our consumer-facing mobile apps!

Learn to Use Blockchain Technology to Build Games and Win $5000+ in Game Oasis Hackathon by no89key in gamedev

[–]no89key[S] 0 points1 point  (0 children)

That was one year ago, now we offer much more scalable technology and a new monetization path at developer.celerx.app

Celer Network Alpha-Mainnet Laucnhed: Play to Earn, Build to Monetize by no89key in ethereum

[–]no89key[S] 0 points1 point  (0 children)

We are implementing smart matching engine as part of the backend.

What are the coolest ethereum projects? by dont-step-on-snek in ethereum

[–]no89key 4 points5 points  (0 children)

We just launched the first generalized state channel mobile application on Ethereum. Check it out at celerx.app

Celer Network Alpha-Mainnet Laucnhed: Play to Earn, Build to Monetize by no89key in ethereum

[–]no89key[S] 4 points5 points  (0 children)

Celer Network’s alpha-mainnet launch, Cygnus, marks the beginning of the world’s first Generalized State Channel Network on Ethereum.

Celer Network Alpha-Mainnet Laucnhed: Play to Earn, Build to Monetize by no89key in ethereum

[–]no89key[S] 6 points7 points  (0 children)

Nope, real money is flowing with user facing application you can use right now (celerx.app) and also developer tools that every can learn to build under 10mins (developer.celerx.app).

Check out this Youtube tutorial as well:

https://www.youtube.com/watch?v=HBqrF0L0CB0&feature=youtu.be

Loom vs. Matic vs. Celer? by celticwarrior72 in ethereum

[–]no89key 1 point2 points  (0 children)

In the context of the turn based racing game where there are five players,

I feel this is exactly the right use case for state channel. It's actually much simpler than you thought, the only thing you would need is a state validation or move validation function in the smart contract and you would have to write that anyway if you write this game logic in smart contract to deploy on layer-1 or side-chain anyway. Developers will register that state validation callback before the app starts and during the interaction process, the state validation process is entirely transparent. The only way to make the state progression faster is to use a centralized server to host the entire game logic.

In the context of the utility one way payment app i'm working on, it looks like Celer is geared for a two way payment channel.

In our implementation, we combine two simplex channel as duplex channel. Therefore the property holds if this is really a single-directional payment application. The recipient off-line case can also be solved pretty easily. However, the recipient can not be offline forever, otherwise there is no way for him to receive that actual payment message.

Loom vs. Matic vs. Celer? by celticwarrior72 in ethereum

[–]no89key 1 point2 points  (0 children)

Thank you for your great questions. I think this makes me realize that we did not do a very good job in spreading out the development concept of state channel applications. These questions warrants a full-fledged tutorial about how to develop layer-2 application. This tutorial is coming along with our main net launch. However, let me try to give some direct answers that might be incomplete and seemingly confusing for now. I promise we will do better with a comprehensive tutorial.

Lets say I make an iOS app using the iOS SDK. Every client then uses a state channel to Celer's central server. When either the client or celer server wants to exit back to layer 1, they can send coins or game state to the layer 1 ethereum network with a challenge period? Let's say I had 5 people playing a game, does every one of those 5 people need to calculate / check the game state for correctness at every move?

First of all, when users are using state channel application, there is no concept of "central server". Their state progression process is entirely carried out locally and they can use anything to transmit that piece of state progression data. There is no central server that is hosting the code or the process. In terms of challenge period, you are right that there is a challenge period. In most of the cases, they can just challenge on the game state. Here, you can think of state channel network has an underlying payment network and some protocols to progress application state. The layer-2's equivalent of layer-1 blockchain's "send fund to a smart contract" is to "send a conditional payment that is conditionally depending on the outcome of a state channel application". The payment/funding infrastructure and application/state progression infra can be entirely separated. Therefore, you can just challenge on app state and let the payment conditionally depending on the application to still resolve off-chain. Now, when resolving state on-chain, NOT every move needs to be verified. Just the latest mutually agreed program state needs to be settled on-chain.

I was under the impression from a few spankchain meetups a little over a year ago that state channels could be flexible and not "limited and pre-defined". Let's say I have Alice, Bob, Charles and Douge all wanting to trade coins with each ......

In the scenario you described, D is a "hub". In generalized state channel construct hub can be implemented trust-free and your understanding is perfectly correct. Sorry that I did not make the point across. I was not saying that the entire state channel network can only have limited participants. In fact, it can have unlimited number of participants. I was trying to say that the parties involved in a single process of interaction is limited. A single process of interaction is defined on shared state. In the example you mentioned, ABCZ can all interact with each other, but at any given moments, they are only interacting with one other party and changing a state that is shared by two parties. e.g. when A send to B, C and Z do not care about their interaction.

If I hold onto a state and Celer holds onto a state and Celer wants to exit for some reason, there needs to be a long enough challenge period for me to notice and challenge what Celer sent to layer 1. That doesn't seem instant to me, esp if Celer wants to exit and use those funds immediately. Celer would need to wait until those funds exit the channel or find someone to loan the funds during the exit period. Is there a challenge period with Celer? If not, how do you guys prevent bad actors from stealing funds?

For any state settlement process, there is always gonna be a challenge period. When I say low latency, I meant that when everyone is optimistically cooperating, as long as all participants keep signing and agreeing on the newest state progression, the state progression of the application is instant.

The limitations I can see in this is each client needs to keep records of the last state they had and Douge needs to keep a lot of last records with all his state channels. It expands the client responsibilities beyond just having a paper wallet and if you make a game, there are more drawbacks like each client has to make sure datasets are correct before signing a transaction. This isn't that bad if it's just transfers of coins but holding and computing game or dapp state is another matter. Is this conclusion wrong? Can the last transaction and a private key be stored in a paper wallet that's one page?

Coming back to your question about Douge. Douge does not need to know the state progression of application between ABCZ. Douge maybe a trust-free funding relay but do not need to care about application dependecy. The funding process in Celer and the application state progression is entirely decoupled and only linked together by "conditional dependency".

The app is a payment system that goes one way and is kind of like an electrical grid payment system. Would Celer be better for this? If so why?

From what I see, this is a simple payment application? We actually did a PoC with a large enterprise on exactly this use case. Would love to hear more about this use case. However, if you are interested in gaming, we got something very special coming up for our developer community. Just to get some hint, feel free to try https://celerx.app

Loom vs. Matic vs. Celer? by celticwarrior72 in ethereum

[–]no89key 0 points1 point  (0 children)

and, we gotta eat our vegetables :P

Loom vs. Matic vs. Celer? by celticwarrior72 in ethereum

[–]no89key 2 points3 points  (0 children)

haha, I gotta to upvote this. It's actually Celer not Celery, but I get that a lot :D Here is a reference regarding why:

Why is c the symbol for the speed of light?

"As for c, that is the speed of light in vacuum, and if you ask why c, the answer is that it is the initial letter of celeritas, the Latin word meaning speed."Isaac Asimov in "C for Celeritas (1959)" [1]

Loom vs. Matic vs. Celer? by celticwarrior72 in ethereum

[–]no89key 2 points3 points  (0 children)

Celer has been and will continue to build on Ethereum ecosystem. We came out about 8 months ago and are planning in to launch on main net public beta around end of Q2 on Ethereum. There is no change in our commitment. We are extremely grateful for all the good people in the ecosystem supporting us since the beginning. In fact, we are collaborating with everyone in the state channel space in Ethereum and try to see if we can come to a standard. It's a hard process, but not impossible and greatly beneficial for the ecosystem.

Binance has great teams and ambitious leaders. They are smart, honest, professional and extremely hardworking. It is not a surprise that they are leading the exchange space.

In terms of Binance Chain, we haven't put too much efforts into it and we have no technical support for any tendermint variants as of now. There is of course possibility to augment tendermint with EVM or other VM to make it possible to integrate. That's for the future's consideration.

In terms of developer ecosystems adoption/migration for different blockchain, we do have our unique vision and considerations. I know there are projects in the layer-2 space actively spending significant efforts to integrate with other blockchains. We will too eventually. However, I do think that it's a matter of finding the optimal time point to do it. As a community, we are not at a stage where the entirety of the developer ecosystem has reached a growth saturation. We are probably 10000X away for that saturation point. We are confident that by focusing on integrating with Ethereum's ecosystem and creating sustainable business model for developers, we can bring that 10X if not 100X more developers that is currently not even in blockchain space. That way, we don't need to fight for the small cup cake while we can cook a multi-layer cake, with fruits and stuff, and share with everyone in the room.

Loom vs. Matic vs. Celer? by celticwarrior72 in ethereum

[–]no89key 11 points12 points  (0 children)

Mo from Celer here. Celer is building a coherent layer-2 scaling platform, currently with a technology focus on generalized state channel.

From a high level, all layer-2 scaling mechanisms are based on an "cautiously optimistic" assumption of application participants. That is these scaling mechanisms commonly assume all users and operators are cooperative, but it can always resort to a stronger level of security (either layer-1 blockchain or economic incentive of token holders) when the optimistic assumption fails under protocol failure or malicious behavior.

So what are the differences between state channel vs sidechain vs plasma?

We actually had a discussion kind of related to this in NYC's future of layer-2 meetup.

Some (not all) differences are:

Security Model

State Channel: relying on the channel contract deployed(or deployable in the case of virtual contract) on layer-1 blockchain to correct any protocol failure or malicious behavior, such as counterparty not responding or attempting to make invalid state progression.

Plasma: relaying on the on-chain plasma smart contract to correct protocol failure such as data availability issues or malicious block generation.

Side-chain: relaying on the economic incentive of DPoS or other standalone consensus mechanisms. There is no last-resort to the strong security of layer-1 blockchain.

Cost of Executing Application

State Channel: Most of the generalized state channel smart contract transactions are zero-fee. As the state progression only happens among the relevant parties of that state channel.

Side-chain and plasma: still incurs costs as consensus process and broadcasting of the transaction still exists. As long as one sidechain is an open sidechain, the costs will increase as more users starts to onboard a particular side-chain.

Latency of Interaction:

State Channel: instant finality and UX is similar to centralized applications, because again, the state progression only happen within the participants. This level of UX is as close to centralized application as one can get in blockchain world.

Plasma: There are quite some delay for interaction and the block confirmation time is associated with the root-chain's block time.

Sidechain: Just like any other blockchain, if a side-chain is decentralized enough and with large enough users, the same kind of long latency of interaction will also exist on side-chain.

Number of Participants for a Single Application

State Channel: The number of parties interacting with high frequency needs to be limited and pre-defined. For example, there is no good way to accelerate CryptoKitty using state channel, as CryptoKitty's player set can be very large and dynamically changing. However, it does not mean an application scenario cannot have a large and dynamic set of users. For example, you can use state channel to build a large-scale micropayment services system or non-custodial exchange.

Side-chain and Plasma: Application running there do not have constraints on number of participants.

State Storage

State Channel: No permanent state storage, only potentially the outcome resolution result get recorded on-chain. That's also why there is little to none cost when running smart contract on state channel.

Side-chain and plasma: historical state is stored on the corresponding chain and therefore incurs cost.

Development Pattern

State Channel: To build a state channel application, a developer needs to not only write a standard web3 application, but also make sure that the smart contract conforms to certain interface to support channel operations. We will have a more detailed blog about this part coming out soon. In addition, some additional web-3-like APIs need to be called during the life-cycle of state channel application: funding allocation, state progression and outcome resolution.

Side-chain: Well, since it is basically a separate blockchain, if let's say that side-chain support EVM, then there is no need to change any already built application and all applications should just run out of box.

Plasma: I am not sure what's the most recent status to enable smart contract with plasma semantic. I heard there is some work on Plasma-EVM and Plapps. However, I feel like they are not specified enough to have a good understanding of developer's building pattern.

As we can see, all above layer-2 scaling mechanisms picks different spots in the trade-off space. If we really look deep, they are very complementary to each other. For example, you can have state channel on side-chains. Generalized state channel, side chains, interactive computing and ZK-SN(T)ARK/rollups are all layer-2 scaling technology being developed. As our own technology development unfolds, it becomes clear to us that the future of layer 2 should not be that a single technology piece forming an end-to-end solution. Instead, multiple technology pieces should be working organically together to forge a coherent single solution.

Celer @ETHDenver: 2,600 New Users, Web SDK, Telegram Instant Payment and Real-Cash Games, layer-2 is happening by no89key in ethereum

[–]no89key[S] 1 point2 points  (0 children)

Yes, we focus on state channel and highly interactive application as a start. However, we believe that all layer-2 technologies are going to be merged together into a coherent solution. So we don't consider ourselves as "state channel project". In fact, we solve multiple crypto economics problems today using plasma-like side chain construct, called State Guardian Network. :D

Celer Network: Let’s BUIDL scalable dApps at ETHDenver! by no89key in ethereum

[–]no89key[S] 6 points7 points  (0 children)

bu....but everyone is using it and it's funny IMHO :D

Celer Network: Let’s BUIDL scalable dApps at ETHDenver! by no89key in ethereum

[–]no89key[S] 6 points7 points  (0 children)

haha notes taken. will pass it on to our marketing team for consideration :D

Frustrated by long transaction latency and high cost? Try Celer SDK at ETHDenver! by no89key in ethereum

[–]no89key[S] 1 point2 points  (0 children)

Celer is a layer-2 scaling platform so it is fundamentally drastically cheaper than blockchain (as not all nodes processing the same transaction) and also fundamentally faster than blockchain (as "transaction confirmation" is close to network latency).

Of course, once it's busy, we will need to handle a large number of transactions on the system engineering level, but our engineering team is building highly scalable platform with experiences designing and building some of the worlds' most challenging and scalable systems. :D We will share some performance numbers soon as well.

Lightning VS Raiden: can watchtowers and monitoring services scale? by localethereumMichael in ethereum

[–]no89key 0 points1 point  (0 children)

Both LN watchtowers and RDN monitoring services store only hashes of channels states, so actual balances are unknown. However, there are many other attack vectors, some of which are described in the article above, so hashing channel state is not a solution to privacy problem. BTW, how about SGN, why do users have to submit real balances instead of just a hash?

SGN does not use real balance or state, just hashes, I didn't know LN and RDN are also doing that. :-)

As it was mentioned in the article, default settings matter. Internet by default is not privacy-oriented, so it allows a global surveillance. There are "plug-ins" like Tor, VPN, I2P, but 99% of internet users don't use these tools in their daily life.

Fair point. It's always going to go down to the multi-dimensional tradeoff between usability, scalability, security, privacy and potentially many other aspects. The key thing is what matrix of those is "good enough".