Core Analysis¶

Issue: Determine where the project fits and where it should be avoided.

Technical Analysis¶

• README and project metadata indicate a research/experimental focus: local Testnet, REPL, example trainer keys, and missing release/license info.
• Ops examples show long-run and AUTOUPDATE concepts but lack production-grade update signing, rollback, and integrated monitoring.

Suitable Scenarios (Recommended)¶

1. Protocol/consensus validation: Quickly spin up local nets to validate protocol changes.
2. Contract prototyping: Particularly for JS/TS developers using AssemblyScript to iterate on contracts.
3. Ops/system tuning experiments: Test sysctl, resource limits and auto-update strategies on nodes.

Unsuitable Scenarios (Avoid)¶

• Mainnet/Commercial services: No explicit license/releases/audits—unsuitable for direct production use.
• Compliance-heavy environments: Lacks auditing, key-management, and compliance documentation.
• Cross-platform desktop-first development: README validated only on Linux (Ubuntu 24.04); no guarantees for Windows/macOS.

Important Notice: Treat the project as a lab-grade testbed, not a hosting solution; production attempts need substantial security, audit, and release engineering.

Summary: Use for validation, prototyping, and ops experiments. For production or compliance requirements, pick mature alternatives or invest in significant hardening and governance.

Core Analysis¶

Issue: How to safely and reproducibly start and debug the local testnet while avoiding common misuses shown in the README.

Technical Analysis¶

• README instructs editing /etc/hosts and disabling Chrome cert/CORS—convenient for local debugging but insecure.
• systemd example runs as User=root in /root/, which is risky if copied to non-test systems.
• sysctl/limits changes affect kernel/resource limits and must be validated in controlled setups.

Practical Recommendations (Steps)¶

1. Build: Use podman/docker with the erlang_builder image per README inside containers and export artifacts to host or VM.
2. Run: Launch the node inside a dedicated VM/container; avoid running as root on the host. Configure systemd User to non-privileged account and adjust WorkingDirectory accordingly.
3. Frontend connectivity: Do not permanently disable browser security; use local reverse proxy (Nginx/Traefik) with self-signed certs or trust chain instead of --disable-web-security.
4. System tuning: Apply sysctl/limits changes incrementally in a test environment and document rollback.

Important Notice: Never use sample/trainer keys outside test networks. Do not apply README root or permissive settings to production servers.

Summary: Follow a container -> isolated VM -> staged tuning deployment flow to reproduce functionality while minimizing security and operational risk.

Core Analysis¶

Issue: README provides aggressive kernel/resource tuning and a systemd autostart example; blindly applying them to shared/production hosts introduces risks.

Technical Analysis¶

• Aggressive resource limits: nofile=1048576, memlock unlimited suit high-load nodes but can starve other host processes.
• Network buffer increases: Raising net.core.rmem_max/wmem_max and netdev_max_backlog helps high-throughput UDP but depends on NIC/driver and kernel support.
• systemd example weaknesses: Running as User=root via screen hinders logging, permission isolation, and auditing; AUTOUPDATE without signature checks is risky.

Practical Recommendations¶

1. Stage changes: Validate each sysctl tweak on a stress-test machine, then decide production rollout.
2. Use non-privileged user: Configure systemd User to a dedicated low-privilege account; avoid root.
3. Improve service management: Use Type=simple and log to journal instead of screen, configure Restart and WatchdogSec as appropriate.
4. AUTOUPDATE controls: Add signature verification, version whitelists, and rollback scripts; do not enable unattended updates in production by default.
5. Monitoring & rollback: Monitor dmesg/journal, packet loss/latency after changes and keep rollback steps ready.

Important Notice: Do not broadly relax nofile/memlock on shared or multi-tenant hosts without impact assessment.

Summary: The tuning examples are suitable for dedicated test/high-throughput nodes, but require privilege minimization, update governance, and staged validation before production use.

Core Analysis¶

Issue: How a new team can efficiently onboard, required skills/tools, and a staged learning path.

Technical Analysis¶

• The project combines BEAM (Erlang/Elixir), WASM (AssemblyScript), containerization, and Linux ops; overall learning curve is moderately high.
• README provides build/run and contract invocation examples—suitable for stepwise practice.

Practical Recommendations (Staged Onboarding)¶

1. Environment setup (1-2 days): Install podman/docker, Elixir/Erlang (for REPL/local builds), AssemblyScript (npm i -g assemblyscript), and local wasm runtime (wasmtime or Node WASM support).
2. Build & run examples (2-3 days): Follow README: podman build --tag erlang_builder, ./build.sh, run TESTNET=true ... ./amadeusd, and use REPL Testnet.deploy / Testnet.call.
3. Contract dev & tests (2-4 days): Modify sample in contract_samples/assemblyscript, run unit tests in local wasm runtime, then deploy on-chain and validate.
4. Ops & security (2-3 days): Configure systemd (use non-root user), stage sysctl/limits changes, and set up a reverse proxy instead of disabling browser security.

Important Notice: Validate aggressive sysctl/limits changes and AUTOUPDATE behavior in isolated environments before applying broadly.

Summary: Break onboarding into “env setup → build/run → contract testing → ops hardening” milestones to make the learning curve manageable.

Core Analysis¶

Tech Choices: The project implements node logic on Erlang/Elixir and uses WASM (AssemblyScript in examples) for contract execution sandboxing. The combo balances node reliability with contract language flexibility.

Technical Features¶

• Erlang/Elixir advantages:
• Concurrency & fault tolerance: OTP Supervisors fit many short/long connections and automatic restarts.
• Long-running stability: The BEAM runtime is proven for telecom-grade uptime, aiding long-term operation and self-healing (complements the README systemd/auto-update).
• WASM (AssemblyScript) advantages:
• Language bridge: AssemblyScript lowers the barrier for JS/TS devs to write on-chain contracts.
• Execution isolation: WASM provides sandboxing to reduce direct impacts on node runtime.

Usage Recommendations¶

1. If you need a stable node runtime: Adopt or learn from Erlang/Elixir to leverage OTP observability and fault tolerance.
2. If targeting JS/TS contract authors: Keep AssemblyScript->WASM support to simplify contract development.

Important Notice: Advantages come with operational and developer learning costs—teams must be familiar with OTP/BEAM.

Summary: The stack is well-suited for research: a robust BEAM-based node plus a flexible, sandboxed contract environment for multi-language support.

Core Analysis¶

Issue: How to compile, deploy, and effectively debug AssemblyScript contracts on-chain given WASM debugging limitations.

Technical Analysis¶

• README shows Testnet.deploy "/.../counter.wasm" and Testnet.call, so deployment and invocation paths exist.
• WASM provides sandboxing but typically lacks rich source-level stacks; AssemblyScript debug symbols and node-side log integration are the key gaps.

Practical Recommendations (Deploy & Debug Flow)¶

1. Local build: Use AssemblyScript toolchain (asc) to compile .ts to .wasm, enabling debug options if available.
2. Unit/integration tests: Validate contract logic with local WASM runtime (e.g., wasmtime or Node + wasm) before on-chain deployment.
3. Deploy: Place the generated .wasm into the project and invoke Testnet.deploy via REPL/RPC.
4. Improve logging: Add explicit status returns and logging in the contract; enable node-side contract execution logs to trace behavior.

Important Notice: Do not rely on disabling browser security for debugging remote nodes—use a local proxy and short-lived trusted certificates.

Summary: Deployment is straightforward, but debugging is constrained. Local runtime tests, incremental development, explicit logging, and node-side logs materially improve debugability.