Q5: Согласно предыдущим сведениям, адрес CKB будет объединен с новым форматом после обновления основной сети. Означает ли это, что адрес кошелька CKB всех dApp будет одинаковым, и больше не будет ситуаций, когда одно приложение имеет один уникальный адрес кошелька?
Ян: Это интересный вопрос, потому что он связан с дизайном CKB.
Прежде всего, после этого обновления основной сети формат адреса будет унифицирован в формат фиксированной длины, по крайней мере, для адреса по умолчанию. Почему я подчеркиваю слово «по умолчанию»? Поскольку формат адреса, используемый разработчиками и приложениями, определяется ими, у них есть свобода выбора. Формат адреса — это просто стандарт, и каждый может выбирать, использовать этот стандарт или нет. Что изменилось на этот раз, так это стандарт по умолчанию: предыдущая проблема заключалась в том, что стандарт по умолчанию содержал два формата, длинный адрес и короткий адрес, а новый стандарт имеет только один формат.
Однако это не означает, что адрес кошелька CKB для всех dApps будет одинаковым.
Если адрес не тот, это не обязательно означает, что пользовательский опыт будет плохим. Это совершенно 2 разные проблемы.
По отзывам сообщества мы знаем, почему люди так ненавидят длинные и короткие адреса. Это пользовательский опыт, который не является хорошим. Но эта проблема вызвана не только форматом адреса. Например, давайте посмотрим на уровень SDK. Если предположить, что наша экосистема является зрелой, SDK завершен, Mercury и Lumos завершены, то независимо от того, какой формат адреса существует, эти промежуточные уровни могут поддерживать все это. Таким образом, для кошельков, разработчиков dApps и бирж, так как они используют SDK (Mercury и Lumos), вместо прямого RPC CKB, они могут в конечном итоге добиться хорошего пользовательского опыта.
Если средний слой сконструирован хорошо, вы можете этого не почувствовать, даже если нижний слой имеет 100 адресов. В этом преимущество многослойности, потому что средний слой может скрыть детали нижнего слоя. Предыдущая проблема вызвана недоработкой среднего слоя, поскольку детали нижнего слоя могут проявляться. Это мой взгляд на проблему.
Итак, когда экосистема еще незрелая, стоит ли нам ждать, когда средний слой созреет и найдет идеальное решение для решения этой проблемы, или не стоит ждать и просто изменить формат адреса на унифицированный?
Мы обсудили это с основной командой и сообществом, включая UniPass, .bit. В итоге решили сменить адрес на единый, хотя бы для решения насущной проблемы. Таким образом, не имеет значения, хорошо работает SDK на среднем уровне или нет, по крайней мере, проблем, с которыми мы сталкивались ранее, можно избежать.
Но в будущем в CKB по-прежнему будет несколько адресов, и для каждого dApp могут быть даже разные адреса. Это особенность модели UTXO. Плохой пользовательский опыт, вызванный несколькими адресами, должен решаться на среднем уровне. Поэтому, когда мы разрабатываем Mercury и SDK, мы будем уделять большое внимание рассмотрению того, на какой адрес он будет отображаться, если появится новый скрипт. Если сопоставляется тот же адрес, конечно, проблем нет. Если сопоставляется другой адрес и он отображается на поверхности, должен ли пользователь знать об этом или нет? Как мы спроектируем его так, чтобы пользователи не знали об этом и больше не сталкивались с проблемами между длинными адресами и короткими адресами? Это вопрос, который мы должны рассмотреть в будущем.
Короче говоря, мы фактически приняли решение, которое всех устраивает — единый адрес с фиксированной длиной. В будущем мы должны обсудить, как будет развиваться формат адреса, сохраняя при этом хороший пользовательский интерфейс.
Почему можно иметь несколько адресов? Это очень интересно. Я не знаю, использовали ли вы биткойн-кошелек. Подлинный биткойн-кошелек, такой как Electrum, или кошелек с официальным клиентом по умолчанию сгенерирует для вас множество адресов. Так почему биткойн-кошельки делают это? Не вызовет ли это затруднений? С одной стороны, это связано с тем, что адреса и счета по своей сути являются разными понятиями. Из-за популярности Ethereum многие люди не знают различий между ними. Во-вторых, на самом деле это дает много преимуществ, например, лучшую защиту конфиденциальности. Если есть только один адрес, и все ваши действия связаны с этим адресом, очень легко узнать, кто вы, с помощью анализа больших данных. Если вы хотите защитить свою конфиденциальность, лучше всего использовать новый адрес для каждой транзакции.
Я не знаю, используете ли вы один или несколько адресов в своем кошельке одновременно. На самом деле система учетных записей не очень хороша с точки зрения конфиденциальности. Биткойн-кошельки, такие как Electrum, будут постоянно автоматически менять адреса. Как только вы воспользуетесь одним из них, он сгенерирует для вас новый адрес, а как только вы получите деньги, он также сгенерирует новый адрес.
В дизайне Биткойна учетная запись может иметь бесконечное количество адресов. На самом деле, мы можем сделать это через дизайн системы. Пользователю нужно только запомнить учетную запись. На самом деле им не нужно заботиться о том, 10 адресов или 100 адресов соответствуют его учетной записи, пока средний уровень ниже может помочь ему справиться с этим автоматически. С точки зрения учетной записи активы всех адресов находятся в одной учетной записи, хотя для передачи и получения используются разные адреса. Таким образом, пользовательский опыт такой же.
Если вы можете отделить адрес от учетной записи, на самом деле есть много преимуществ, одним из которых является конфиденциальность, как упоминалось ранее. Еще одно преимущество заключается в том, что, поскольку у меня могут быть разные адреса, мой адрес сам по себе может кодировать информацию, и эта закодированная информация может подсказать кошельку, что делать. Таким образом, протокол между кошельком и приложением станет более мощным.
Наличие нескольких адресов под одной и той же учетной записью на самом деле не критично, и мы можем исследовать это постепенно. Это заслуживает исследования, потому что все привыкли к дизайну Ethereum. Сначала мы улучшим пользовательский опыт, а в будущем мы изучим, каким должен быть базовый дизайн, сохраняя при этом хороший пользовательский опыт.
Сейчас у нас есть четкий принцип: при изучении нового дизайна мы должны поддерживать хороший пользовательский опыт. Это беспроигрышный вариант, которым останутся довольны все.