Watcher Design

[kasima]

We need to have a discussion about the Watcher at a high level since there's a lot of confusion about the vision of what purpose it serves, which leads us to confusion about things like #156.

Rather than tackling individual features ad-hoc, let's talk about how we envision the future of the Watcher.

People have characterized it as:

• A verifier (blocks, withholding, transaction consistency, root chain submissions)
• A full node (non-mining)
• A light node
• An convenience API gateway to the child chain
• A client/wallet

This specifics of what it does and what clients it serves (servers, browsers, wallets, etc.) can lead feature requirements (like whether we want CORS support).

As to actual functional requirements, here's what we need on the integrations end:

Proposed requirements

Block explorer APIs (each endpoint should have filtering capabilities):

• Getting all blocks
• Getting a block and its transactions
• Getting all transactions (paginated, per address, per list of addresses)
• Get specific transaction (by id)
• Getting UTXOs (paginated, per address, per list of addresses?)
• Get balance by address

eWallet APIs:

• Build transaction
• Submit signed transaction
• Get specific transaction (by correlation field)

Events:

• Subscribe to Websocket event endpoints notifying the following events (probably for a list of addresses?):
  • should exit due to [some fault]
  • Standard Exit (MVP)
  • Exit Challenge
  • In-flight exit (MoreVP)
  • Delegated?
  • Exit challenge
  • Challenge response
  • Exited successfully
  • new transaction submitted
  • new deposit
  • transaction shows up in a block
  • new block
  • ...we probably need to add to this list...

UTXO Management

• Merging / splitting / recommendations

Security

• Key management
• Verify consistency

Deployment

• Support multiple instances of watchers per node (many eWallets, many Watchers, 1 plasma node)

This is the beginning of a design discussion. Please drop your opinions in here.

/cc @whoisjeremylam @robinclart @omisego/blockchain @T-Dnzt @Pongch @kevsul @kfichter

[whoisjeremylam]

People have characterized it as: A light node A client/wallet

The Watcher as it is now can't be a light node. A light node doesn't download and store a complete version of a blockchain. The Watcher currently downloads and stores a complete copy of the OMG Network blockchain.

I'm not clear what the definition is for client. Maybe someone could jump in and explain.

Currently, the Watcher isn't a wallet currently because there is no key management.

If the Watcher was to provide wallet services, let's say via a web app for discussion, who would use a wallet in this way?

Key management

I feel that the app layer (like an ewallet) should be responsible for key management. This will give applications flexibility to use different key management strategies, dependent on their needs.

UTXO Management

This is certainly required. However, I don't have a strong opinion on whether this should be within the Watcher or somewhere else. Whilst the Watcher has all the information required for UTXO management, this could be separated.

Deployment Support multiple instances of watchers per node

Does node mean the child chain server? A diagram of the deployment can be seen on https://github.com/omisego/elixir-omg/blob/develop/docs/assets/OMG-network-eWallet.jpg.

This is my current view on the role of the Watcher:

• Checks if the child chain becomes byzantine
• Given the Watcher knows about the health of the child chain, the Watcher can advise if it is safe to submit a transaction to the OMG Network. Practically speaking, this makes the Watcher a candidate to proxy transaction submissions. I agree that it does seem odd that whilst the Watcher seems to be a read only application by name, that it is a endpoint for transaction submission.
• Watcher will raise events to the application if an application needs to perform an action such as challenge an exit.

[Pongch]

My 2 cents- is that we should have consistent naming/conventions/definitions that is somewhat consistent with other blockchain projects.

With that said, other client it serves that is not mentioned here are Decentralized Apps (and I do get asked about how Plasma fits into dApp development workflow a lot). Given that these apps will be predominantly done on the client side with a smart contract as a backend this could be a prevalent use cases for a DEX / Plasma in general.

[smartcontracts]

Along the lines of what @Pongch said, I believe that the watcher should just be called a full node. This is effectively what it is - a standalone node that provides full security guarantees. I think watcher is confusing and almost makes it sound like users can get full security without running their own watcher node (there's a trust assumption).

I think the real question is whether we bundle things like wallet software with the full node. Bitcoin Core offers a (very) rudimentary wallet by default, but most of the "nice" wallets are built by third parties. I think we can follow this same pattern.

[whoisjeremylam]

the watcher should just be called a full node

:+1: I agree with this.

I think the real question is whether we bundle things like wallet software with the full node.

If we were to build in end-user wallet functionality, my concern would be around support and maintenance of this wallet. It's useful to have but it's a product in itself.

[pdobacz]

OK, I'll respond to some bits that were written here in some points, to try to explain my rationale behind the current setup and taxonomy:

tl;dr: I think "Watcher" is a thing of its own and we need some name for it.

1/ somewhat replying to the "consistent with other blockchain projects":

I'm not sure whether we have this option to be consistent. The reason is the dual (or tiered) nature of the security mechanism, which is absent in other blockchain projects. By "dual"/"tiered" I mean that the Watcher is intended to keep track of the activity of one chain (or many tiers of chains) with respect to the root chain. The construction of plasma and exits introduced this concept, which didn't exist before, so in my opinion a new and "inconsistent" term is justified (even if it's not exactly "Watcher" for other reasons)

2/ re "full node"

I have an issue with calling the Watcher a "full node": the concept mentioned in (1/) is present, even if there is no P2P network, and hence there is no nodes. In fact, Watcher's activity is decoupled from how the child chain works - it is solely to track the root chain, pull block contents and validate that. It doesn't matter whether there is a network (which would mandate calling it a "node") or a PoA central operator.

What I would call an OMG network full node, would be a piece of software that either actively creates blocks in some PoS setup or is validating that process in any way, but such validating would validate txs and blocks etc. before submitting to the rootchain not after, as a Watcher would.

3/ my take on the role of Watcher, until this point:

Watcher handles: A/ tracking of the root chain submissions, pulling block contents (from somewhere) and validating, in order to ensure safety of funds passively in possession on the child chain. Watcher notifies in case of the funds are jeopardized B/ proxy API to the child chain API (whatever it may be - PoA server or a P2P PoS network) and the root chain, that ensures that these two are never talked to if the chain is invalid or in unknown state C/ storage of data critical to access of the funds - UTXO positions, txbytes or any other kinds of proofs

and only A+B+C. In particular, Watcher doesn't handle:

• key management of any sort
• as a consequence of the above - signing
• any kind of tracking of the correctness of neither root chain or child chain PoS mechanisms (!) (see decoupling argument)
• wallet
• autonomous actions (like automatic UTXO management, exiting, challenging) - all that is unavailable due to the fact that the Watcher never signs. The watcher should provide information necessary to perform these actions though (and it does already).
• convenience functions like building transactions or computing balances (Yes, I have seen the recent additions, while very useful, they go beyond the "pure Watcher" definition)

The above characteristics make me believe that a "Watcher" is a new kind of software that the users will be running. So it doesn't fit with any of the "usual" terms, like listed:

A verifier
A full node
A light node
An convenience API gateway to the child chain
A client/wallet

4/ re "seem odd that whilst the Watcher seems to be a read only application by name"

Given the "fall through" nature of the proxy, the submission of a plasma or ethereum tx "through" the Watcher's proxy would not alter the state of the Watcher (unless this is required to remain safe and conscious of one's funds). So still the term watcher isn't that bad: the watcher watches the chain, watches over what you do, and watches over the information you broadcast, so it does everything necessary to watch over the user.

[kasima]

Pulled together this discussion and what we covered on the watcher design call here: #215.