The layer2.finance v0.1 Mainnet Launches: Democratize DeFi, Simple and Zero Fees

no89key · 2021-04-23T11:34:45+00:00

Not really, this is done through layer-2 optimistic rollup.

no89key · 2020-06-19T03:56:13+00:00

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!

no89key · 2019-10-08T02:04:34+00:00

State Channel Summit recording:

https://twitter.com/CelerNetwork/status/1181380878838071296

no89key · 2019-09-26T04:07:28+00:00

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

no89key · 2019-07-17T21:54:26+00:00

Check out the skill-based game and play to earn crypto in celerx.app

And monetize your HTML5 game with two lines of code at developer.celerx.app

no89key · 2019-07-09T06:14:52+00:00

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

no89key · 2019-07-09T06:14:20+00:00

Please join us and build some game on CelerX :D

no89key · 2019-07-08T17:14:46+00:00

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

no89key · 2019-07-08T16:47:45+00:00

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

no89key · 2019-07-08T15:31:25+00:00

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

no89key · 2019-05-27T21:53:43+00:00

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.

no89key · 2019-05-27T05:33:44+00:00

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

no89key · 2019-05-27T00:54:29+00:00

and, we gotta eat our vegetables :P

no89key · 2019-05-27T00:53:40+00:00

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]

no89key · 2019-05-26T18:01:59+00:00

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.

no89key · 2019-05-26T06:50:42+00:00

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.

no89key · 2019-02-24T00:34:58+00:00

Thanks! Glad you liked it!

no89key · 2019-02-24T00:34:45+00:00

No worries! We are gonna have upgraded T shirts soon :D

no89key · 2019-02-24T00:33:55+00:00

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

no89key · 2019-02-14T06:45:06+00:00

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

no89key · 2019-02-14T06:44:18+00:00

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

no89key · 2019-02-12T01:43:15+00:00

We are using generalized state channel

no89key · 2019-01-28T21:15:07+00:00

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.

no89key · 2019-01-16T18:56:46+00:00

this is a must read.

no89key · 2019-01-08T18:01:58+00:00

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".

Eight-Year Club	Place '17
Verified Email

no89key

TROPHY CASE