chore: update contract deployment docs (#63)

* chore: update contract deployment docs

We don't use nx in the contract repo, so these deploy instructions
need a little update.

* docs: explain how auth server uses sdk

The deployment for new chains is a little short on details, but
that's probably better to include in zkstack cli, since those tools
are outside of this repo

---------

Co-authored-by: yuliyaalexiev <158060999+yuliyaalexiev@users.noreply.github.com>

Author: cpb8010

README.md

@@ -199,7 +199,7 @@ To execute the end-to-end tests for the `demo-app` (or similarly for
 
 1. Start `era_test_node` (In a separate terminal, run
    `npx zksync-cli dev start`)
-2. Deploy the smart contracts, `pnpm nx deploy contracts`
+2. Deploy the smart contracts, `pnpm --dir packages/contracts run deploy`
 
 Once the local node is configured with the smart contracts deployed, you can run
 the e2e tests:

docs/nx-cheatsheet.md

@@ -11,7 +11,6 @@ in the workspace's `project.json`, not the directory name.
 ```bash
 pnpm nx <target> <project>
 # examples
-# pnpm nx deploy contracts
 # pnpm nx serve auth-server
 # pnpm nx build sdk
 ```

examples/bank-demo/README.md

@@ -26,10 +26,12 @@ Account session and data is stored via the browser Local storage.
 
 ## Deploying the Bank demo to Firebase
 
-The Bank demo app uses Demo Node (`https://node.nvillanueva.com`).
+The Bank demo app uses Demo Node (`https://node.nvillanueva.com`). Add your
+deployer private key to the .env file (packages/contracts/.env)
 
 1. Deploy the latest contracts with
-   `pnpm nx deploy contracts -- --network demoNode`.
+
+   `pnpm --dir packages/contracts run deploy --network demoNode`.
 
 2. Update `nuxt.config.ts` contract addresses under `$production`.
 

examples/nft-quest/README.md

@@ -8,8 +8,8 @@ Run the following (be sure a local node is running, e.g.
 `era_test_node`[https://docs.zksync.io/build/zksync-cli/running-a-node]):
 
 ```sh
-# Deploy the ZKsync SSO contracts
-pnpm nx deploy contracts
+# Deploy the ZKsync SSO contracts (when run from the root)
+pnpm --dir packages/contracts run deploy
 
 # Deploy the contracts for the NFT Quest Demo
 pnpm nx deploy:local nft-quest-contracts

packages/auth-server/README.md

@@ -7,8 +7,66 @@ ZKsync SSO Auth Server
 ```sh
 # Ensure era_test_node is already running (npx zksync-cli dev start)
 # Deploy ZKsync SSO smart contracts
-pnpm nx deploy contracts
+pnpm --dir packages/contracts run deploy
 
 # Start Auth Server
 pnpm nx dev auth-server
 ```
+
+## How to deploy to a new chain
+
+If you are a ZKsync chain operator, there are a few more updates to make to
+deploy.
+
+Deploy the timestamp asserter and update the TimestampLocator.sol with your
+chain id.
+
+Adding contracts to the storage slot allow list (api_web3_json_rpc:
+whitelisted_tokens_for_aa)
+
+Include the addresses of SSO WebAuthValidator, SSO SessionKeyValidator, SSO
+Beacon which need to be updated by the chain id in contractsByChain in the
+client file. The block explorer url in the same file can also be updated if your
+chain is listed in viem/chains.
+
+## Design
+
+The auth server is designed to run as a static front-end that facilitates
+passkey signing and session creation via a trusted domain. The SDK has a wagmi
+connector that points users to this project.
+
+### Communication
+
+The auth-server expects to managed via pop-up, so the client-auth-server uses
+the pop-up communicator component to send the transaction request via
+window.postMessage. The auth-server listens to this message and the loads the
+UI, which then drives the user either through the sign-in with passkey or create
+account flow.
+
+It uses a custom RPC format to send success and status messages back to the SDK
+for the session request data.
+
+### Account Deployment
+
+The account deployment and on-chain interaction for passkey signing and session
+creation both happen within the auth server (session key signing happens
+outside). This requires that the auth-server is connected to a paymaster, as the
+deployment is performed from a random address for each deployment.
+
+The auth server _currently_ uses the passkey credential id as the unique account
+id if it's not provided, it then checks the account deployment factory to log a
+user in as the factory stores a mapping from passkey id to account address.
+
+### Dashboard
+
+The auth server expects both the session key and passkey module to be installed,
+so builds in dashboards for the modules to view basic information on sessions
+and passkeys. It depends on the SDK's definition of SessionConfig to parse the
+session for the user before approval. It reads the session status directly from
+the chain and then relies on the SDK's contract ABI for the session key
+validation module.
+
+### Storage
+
+To reduce user friction after signing in or signing up, the account information
+is kept in browser local storage tied to the auth server domain.