Starknet 训练营-课程笔记4

Task4：https://wj.qq.com/s2/25470592/18pd/

为什么仅有智能合约还不足以发布一个完整应用？

A. 合约不能部署到主网
B. 合约无法处理用户输入
C. 应用还需要前端或移动端与合约进行交互
D. 合约无法存储状态

正确答案：C

核心原因解析

智能合约本质是运行在区块链上的后端逻辑代码，负责处理业务规则、状态存储、交易执行等核心功能，但它本身无法直接触达终端用户。一个完整的去中心化应用（DApp）需要前端/移动端与智能合约协同工作，原因如下：

  1. 用户交互层缺失
    智能合约没有可视化界面，普通用户无法直接通过区块链节点调用合约方法（如发起转账、铸造NFT）。必须通过前端页面（Web/H5）、移动端App等载体，将用户操作（点击按钮、填写表单）转化为区块链交易请求，再通过钱包（如MetaMask、Trust Wallet）签名后发送至合约。

  2. 选项排除逻辑

    • A错误：智能合约的核心价值就是部署到主网（如以太坊、Monad）才能实现去中心化运行，部署是发布应用的必要步骤而非障碍。
    • B错误：合约可以通过交易参数接收用户输入（例如调用mintNFT(address to, uint256 tokenId)时，to和tokenId就是用户传入的参数），只是需要前端作为参数传递的中介。
    • D错误：智能合约的核心特性之一就是状态存储（例如NFT合约存储所有权映射、DeFi合约存储用户余额），区块链的持久化特性保证了合约状态的不可篡改。

补充：完整DApp的技术架构（以你的「图书金库NFT终焉大盘系统」为例）

层级 核心功能 技术示例（Web3场景）
前端层 用户交互、数据展示、交易签名 React/Vue构建页面，Ethers.js/Web3.js对接合约
智能合约层 业务逻辑、状态管理、交易执行 Solidity/Monad合约编写，实现NFT铸造/查询逻辑
区块链层 合约部署、交易上链、状态共识 Monad主网/测试网，节点验证与数据存储

对于黑客松开发或生产级DApp而言，前端与合约的交互效率（如通过RPC节点优化请求速度、处理链上数据异步返回）直接影响用户体验，这也是Web3开发者需要重点打磨的环节。

Starknet.js 中，Account 类的主要职责是？， 单选

A. 编译合约
B. 管理账户、签名并发送交易
C. 监听事件
D. 存储合约 ABI

正确答案：B

核心解析

Starknet.js 中的 Account 类是与Starknet账户交互的核心类，专门封装了账户相关的核心能力，也是开发者操作Starknet账户的主要入口，其核心职责就是管理账户、对交易进行签名并发送至Starknet网络，对应选项B。

简单来说，Account 类就像你在Starknet网络中的「操作终端」，所有需要以账户身份执行的操作（比如调用合约、发起转账），都需要通过它完成签名（证明是账户持有者操作） 和交易发送（提交到网络执行），同时它会管理账户地址、私钥/签名器等核心账户信息。

选项排除逻辑

  • A错误：Starknet.js中编译合约的能力由专门的工具/类实现（如starknet-compile、ContractCompiler等），Account 类不涉及编译逻辑。
  • C错误：监听链上事件是Starknet.js中 Provider 类的核心能力之一（通过provider.onEvent()等方法），Account 类无事件监听的封装，事件监听是网络层的能力，而非账户层。
  • D错误：合约ABI 是开发者在创建Contract实例时手动传入的参数，仅作为合约交互的「接口说明」，不会由Account 类存储，Account 也不负责管理ABI相关数据。

补充：Starknet.js中核心类的职责区分（易混点）

核心类 核心职责
Account 账户管理、交易签名、交易发送
Provider 网络连接、事件监听、查询链上数据（如区块、交易状态）
Contract 对接智能合约、调用合约方法（需结合Account签名）

总结

Starknet.js中Account类的核心是账户操作与交易签名发送，是执行账户级操作的核心入口，也是区分「无签名的合约调用」和「有效链上交易」的关键类。

用于读取合约状态的 Starknet-react Hook 是？

A. useSendTransaction
B. useAccount
C. useReadContract
D. useProvider

正确答案：C

核心解析

Starknet-react 是专门为 Starknet 生态设计的 React 开发库，其封装的 Hook 严格遵循功能单一性原则，useReadContract 是专门用于读取Starknet智能合约的状态/只读方法的 Hook，直接对应「读取合约状态」的需求。

简单来说，合约中无需签名、仅做数据查询的方法（比如查询NFT余额、代币持仓、合约配置参数等只读操作），都通过 useReadContract 实现，它会封装好与合约的只读交互逻辑，自动处理请求、返回数据和加载/错误状态，是前端读取Starknet合约状态的核心Hook。

选项排除逻辑

  • A错误：useSendTransaction 用于发送需要签名的链上交易（比如调用合约的转账、铸造、修改状态方法），是「写操作」Hook，与「读取合约状态」的读操作完全相反。
  • B错误：useAccount 用于获取当前连接的Starknet钱包账户信息（比如账户地址、是否连接、签名器实例等），仅管理账户相关状态，不涉及合约交互。
  • D错误：useProvider 用于获取Starknet的Provider实例，Provider是网络连接核心，仅提供底层的链上查询、事件监听能力，不直接封装「合约状态读取」的业务逻辑，需手动结合合约ABI调用，而非专用的合约读Hook。

补充：Starknet-react 核心常用Hook 职责区分（开发高频用）

Hook 名称 核心职责 操作类型
useReadContract 读取合约状态/调用合约只读方法 读操作（无需签名）
useSendTransaction 发送签名交易、调用合约写方法 写操作（需要账户）
useAccount 获取当前连接的钱包账户信息 账户状态管理
useProvider 获取Starknet Provider实例 底层网络能力
useContract 初始化合约实例（结合ABI/地址） 合约实例封装

总结

  1. Starknet-react 中读合约状态的专用Hook是useReadContract，适配所有合约只读操作；
  2. 读操作（useReadContract）无需账户签名，写操作（useSendTransaction）依赖useAccount获取的账户；
  3. useProvider/useAccount是基础能力Hook，不直接负责合约的读/写交互。

Scaffold Stark 在工具抽象层级上属于哪一类？

A. 最底层 SDK
B. 仅合约工具
C. 前端组件库
D. 全栈开发脚手架

正确答案：D

核心解析

Scaffold Stark 是Starknet生态专属的全栈开发脚手架，它并非单一功能的工具/库，而是整合了Starknet开发全流程所需的合约层、前端层、开发工具链、部署脚本等所有核心能力的一站式开发框架，能让开发者快速初始化一个可直接开发、调试、部署的Starknet去中心化应用（DApp）项目，对应选项D。

简单来说，Scaffold Stark 就像Starknet开发的「项目模板+工具集」，开箱即用包含Solidity/Cairo合约模板、React+Starknet-react的前端工程、合约编译/部署/测试脚本、链上交互封装等全栈能力，开发者无需从零搭建项目架构，直接基于它开发业务逻辑即可，大幅降低Starknet全栈DApp的开发门槛。

选项排除逻辑

  • A错误：最底层SDK指的是Starknet.js、Starkli这类直接对接Starknet底层协议的工具，Scaffold Stark基于这些底层SDK进行了更高层级的封装，并非底层SDK本身。
  • B错误：Scaffold Stark 不仅包含合约相关工具（编译、部署、测试），还整合了完整的前端工程、交互逻辑、开发环境配置，远不止合约工具的范畴。
  • C错误：前端组件库仅聚焦前端UI/交互组件的封装（如Starknet的钱包连接组件、交易按钮组件），而Scaffold Stark 是全栈架构，前端只是其一部分，核心价值是整合全栈开发流程，并非单纯的前端组件库。

补充：Scaffold Stark 的核心整合能力（全栈特性）

Scaffold Stark 作为全栈脚手架，核心整合了Starknet开发的「合约+前端+工具」三大核心模块，典型能力包括：

  1. 合约层：内置Cairo合约模板（如ERC20/ERC721）、合约编译/部署/测试脚本、本地节点适配；
  2. 前端层：基于React+Starknet-react搭建的前端工程，封装钱包连接、合约读写、交易状态展示等通用逻辑；
  3. 工具链：整合Starkli、Scarb、Hardhat-Starknet等Starknet核心开发工具，统一开发/调试/部署命令。

总结

  1. Scaffold Stark 是Starknet生态的全栈开发脚手架，核心价值是整合全栈开发能力、快速初始化DApp项目；
  2. 它基于Starknet.js等底层SDK封装，并非单一的合约工具/前端组件库；
  3. 这类脚手架的核心作用是提效，让开发者从「搭建项目架构」转向「专注业务开发」。

使用 Scaffold Stark 的一个核心优势是？， 单选

A. 自动帮你写合约逻辑
B. 减少版本兼容问题并提供最佳实践模板
C. 不需要学习 Cairo
D. 自动通过安全审计

正确答案：B

核心解析

Scaffold Stark 作为Starknet生态的全栈开发脚手架，其核心设计目标是标准化Starknet DApp的开发流程——它会提前整合好生态中兼容的工具链、依赖版本，同时内置经过验证的Starknet开发最佳实践模板（合约层、前端层、部署流程均遵循生态规范），让开发者无需手动调试各类工具的版本适配问题，也不用从零摸索合规的开发架构，这是使用它的核心优势，直接对应选项B。

简单来说，Scaffold Stark 帮开发者做好了开发环境的「底层基建」和「规范模板」，解决了Starknet开发中工具多、版本杂、新手易踩适配坑的核心痛点，大幅提升开发效率。

选项排除逻辑

  • A错误：Scaffold Stark 仅提供合约基础模板（如ERC20/ERC721的Cairo基础代码），但不会自动编写业务相关的合约逻辑（比如NFT的铸造规则、DeFi的计息逻辑），核心业务逻辑仍需开发者根据需求自主开发。
  • C错误：使用Scaffold Stark 开发Starknet合约，本质还是基于Cairo语言进行开发（脚手架内置的是Cairo合约模板），开发者仍需掌握Cairo的基础语法和开发规范，无法跳过Cairo的学习。
  • D错误：Scaffold Stark 仅提供开发层面的最佳实践，但不会自动完成安全审计，也无法保证开发者基于模板编写的业务代码无安全漏洞。智能合约的安全审计需要专业的审计团队/工具（如Slither、CertiK）完成，脚手架不具备该能力。

补充：Scaffold Stark 优势的实际开发体现

在实际开发中，选项B的优势会直接体现在两个核心场景：

  1. 版本兼容：无需手动匹配Scarb、Starkli、Starknet.js、Starknet-react的版本，脚手架已整合好相互兼容的版本组合，避免出现「工具版本冲突导致编译/部署失败」的问题；
  2. 最佳实践：前端层封装了标准化的钱包连接、合约读写、交易状态展示逻辑，合约层遵循Starknet生态的合约开发规范，部署层提供了测试网/主网的标准化部署脚本，新手可直接基于规范开发，避免不规范的代码设计。

总结

  1. Scaffold Stark 的核心优势是解决版本兼容痛点+提供生态最佳实践模板，让开发者聚焦业务开发而非环境搭建；
  2. 它是「开发提效工具」，而非「代开发/免学习/自动审计工具」，核心业务开发、语言学习、安全审计仍需开发者自主完成；
  3. 该优势对Starknet新手尤为重要，能大幅降低入门的试错成本。