description: Instructions for setting up Clef to seal blocks on a Clique network
---
Clique is a proof-of-authority system where new blocks can be created by authorized ‘signers’ only. The initial set of authorized signers is configured in the genesis block. Signers can be authorized and de-authorized using a voting mechanism, thus allowing the set of signers to change while the blockchain operates. Signing blocks in Clique networks classically uses the "unlock" feature of Geth so that each node is always ready to sign without requiring a user to manually provide authorization.
However, using the `--unlock` flag is generally a highly dangerous thing to do because it is indiscriminate, i.e. if an account is unlocked and an attacker obtains access to the RPC api, the attacker can sign anything without supplying a password.
Clef provides a way to safely circumvent `--unlock` while maintaining a enough automation for the network to be useable.
It is useful to have basic knowledge of private networks and Clef. These topics are covered on our [private networks](/docs/developers/geth-developer/private-network) and [Introduction to Clef](/docs/tools/Clef/introduction) pages.
With that done, `clef` can be made aware of the password. To do this `setpw <address>` is invoked to store a password for a given address. `clef` asks for the password, and it also asks for the master-password, in order to update and store the new secrets inside the vault.
Clef rules allow a piece of Javascript take over the Approve/Deny decision. The Javascript snippet has access to the same information as the manual operator.
The first approach, which approves listing, and returns the request data for `ApproveListing`, is demonstrated below:
```js
function ApproveListing() {
return 'Approve';
}
function ApproveSignData(r) {
console.log('In Approve Sign data');
console.log(JSON.stringify(r));
}
```
In order to use a certain ruleset, it must first be 'attested'. This is to prevent someone from modifying a ruleset-file on disk after creation.
Once Geth starts asking `clef` to seal blocks, the data will be displayed. From that data, rules can be defined that allow signing clique headers but nothing else.
The actual data that gets passed to the js environment (and which the ruleset display in the terminal) looks as follows:
However, `messages` could also be used. They do not come from the external caller, but are generated inernally: `clef` parsed the incoming request and verified the Clique wellformedness of the content. The following simply checks for such a message:
```js
function OnSignerStartup(info) {}
function ApproveListing() {
return 'Approve';
}
function ApproveSignData(r) {
if (r.content_type == 'application/x-clique-header') {
for (var i = 0; i <r.messages.length;i++){
var msg = r.messages[i];
if (msg.name == 'Clique header' && msg.type == 'clique') {
If an attacker find the Clef "external" interface (which would only happen if you start it with `http` enabled), they
- cannot make it sign arbitrary transactions,
- cannot sign arbitrary data message,
However, they could still make it sign e.g. 1000 versions of a certain block height, making the chain very unstable.
It is possible for rule execution to be stateful (i.e. storing data). In this case, one could, for example, store what block heights have been sealed and reject sealing a particular block height twice. In other words, these rules could be used to build a miniature version of an execution layer slashing-db.
The `clique header 2 [0xae525b65bc7f711bc136f502650039cd6959c3abc28fdf0ebfe2a5f85c92f3b6]` line is split, and the number stored using `storage.get` and `storage.put`:
```js
function OnSignerStartup(info) {}
function ApproveListing() {
return 'Approve';
}
function ApproveSignData(r) {
if (r.content_type != 'application/x-clique-header') {
return 'Reject';
}
for (var i = 0; i <r.messages.length;i++){
var msg = r.messages[i];
if (msg.name == 'Clique header' && msg.type == 'clique') {
var number = parseInt(msg.value.split(' ')[2]);
var latest = storage.get('lastblock') || 0;
console.log('number', number, 'latest', latest);
if (number > latest) {
storage.put('lastblock', number);
return 'Approve';
}
}
}
return 'Reject';
}
```
Running with this ruleset:
```terminal
JS:> number 45 latest 44
INFO [06-16|22:26:43.023] Op approved
DEBUG[06-16|22:26:44.305] Served account_signData reqid=3 duration=1.287465394s
JS:> number 46 latest 45
INFO [06-16|22:26:44.313] Op approved
DEBUG[06-16|22:26:45.317] Served account_signData reqid=4 duration=1.010612774s
```
This might be a bit over-the-top, security-wise, and may cause problems if, for some reason, a clique-deadlock needs to be resolved by rolling back and continuing on a side-chain. It is mainly meant as a demonstration that rules can use Javascript and statefulness to construct very intricate signing logic.
Clef can be used as a signer that automatically seals Clique blocks. This is a much more secure option than unlocking accounts using Geth's built-in account manager.
