#Dec 11 Namada Validator Circle π‘
1 messages Β· Page 1 of 1 (latest)
gm
Hi!
π
Hi
evening all
hello!
Polaris has confirmed that they've been able to make privacy vaults work using Namada π
wow, the weeks are flying by
question on that, is it intentional namada branding / name is not showing anywhere on their "private pools"?
awesome news!
not sure, i can ask
Do you have any feedback about the user experience?
Is there any timeline for a production version?
not yet
there's at least one weird thing happening with the infra (maybe rpc, not sure yet)
I'm thinking about this. Do we want Namada branding on something labeled private pools?
is that just token go up thinking? or good marketing for Namada?
if it's really namada they are depositing into, I think a resounding yes.
they might be keeping the UI simple? Namada will end up a swappable asset on there and so it might be confusing to see the name in multiple contexts?
ok, for sure
they need to know what to do on Namada to manage it?
good marketing. and tbh I mean we don't have to actively work against token go up π
What do you mean by that ? Today we're facing an issue with our public RPC. It crashed failed tostarted. We had to cleanup everything and rebuild it
i'm not exactly sure i remember well enough. @static kestrel or @dusty basin would know, not sure if @sleek beacon has the download yet
post logs in #infra-chatter?
a small 'powered by Namada' motif underneath would be cool tbh
No logs. The node failed to start and the error was about unable to read the genesis file
just gonna cc @sleek beacon to be sure he sees
it's probably a good time to review the validator cpgf subsidy (thanks to @pure mural for beginning this!)
Non-technical question. How's the progress with getting access to the X-account? It would be great to add some technical information about what the latest updates have brought.
a number of validators have deactivated, so we can consolidate the subsidy to increase the amounts for active validators without increasing the total
quite a few jailed since the update too, stuck with wrong state root at upgrade height (apphash error) is my guess
great Q
i spent the last week or so in π¨π
we're trying to figure out how to support Namada independently so that Anoma decisions don't affect Namada and vice versa. the discussion is still evolving, so i don't quite have an update to share
we were ready to post a community PGF proposal a few weeks ago, but this also got blocked by these discussions
one could argue the decision to currently withhold access to twitter account is definitely affecting Namada though!
hey ppl
Can you share some information about the current situation with Namada and Anoma? What is the essence of the problem?
there was concern that attention to Namada could resurface the zachbtc accusation tweets. my understanding is that these caused a lot of disruption to Anoma partnerships in the recent past, and the concern was that it could derail current objectives
We know the number of unique users per month on Polaris ?
Swap data would probably be interesting here.
It could help estimate what fraction of it might use Namada.
good Q! i don't
i could ask the team if this is something they'd be up for sharing
yes please
okay i've posted a msg asking π
i know i have more updates, but i'm pretty wiped and the guy sitting next to me on the plane is literally sleeping on me
would it be okay if i left the circle early? haha
Besides Polaris and Borderless, do you have any insights you could share about possible teams interested in integrating with Namada?
i can't yet--really everything has been focused on the issue of independence
once we get that settled, we can sprint forward
slap him
So Namada's success would come with a well-known on-chain analyst throwing accusations to the team for the tokenomics? Free marketing it's what I'm seeing, there's no bad marketing, but I understand team wanted to protect somewhat Anoma during its expansion (happening these days)
Protocol adapter is now in Base eg
that's what i thought at the time, but i think some kinds of partners use tweets like those as heuristics when deciding whether or not they should entertain working with a project
next Validator Circle lands on Dec 25, which is a holiday for a lot of the world π
i'll make a chat for those that still wanna get together π
Yeah will be at home at 25
w.r.t the issues during upgrade, it would be nice to make the process more forgiving, quite a few found themselve stuck with the wrong state committed to db after inadvertently finalising block 4514500 with v101
wdym by more forgiving?
mainly: is there a way to allow the upgraded version to pick up and carry on even though the wrong version was running at upgrade height
currently it looks like rollback is needed, but namadan ledger rollback --help warns to make backups, also takes 10-15 minutes on my system
oh! i suspect for consensus-breaking changes, probably not
@sleek beacon do you know?
also it looks like quite a few resorted to syncing from snapshot, when a rollback would fix it faster
but then again are rollbacks risky and backups have to be made?
urgency on this depends on how soon another breaking upgrade is needed I suppose
In the new version, the consensus algorithm and version updates have changedβthis is now the direct responsibility of validators, who must use their nodes to confirm their agreement with the proposed blocks.
i think by informing vals in the next upgrade to not apply automated restarts or enforce node stopping during the halt process, would be enough, but it's indeed a thing to investigate what happened in the latest upgrade
In the case of Namada, it is necessary for a number of top validators to take a responsible approach to the update))
i'd like for this to be soon! next major upgrade will have direct-to-znam "memoless" deposits
no, validators need to rollback and the nodes need to compute the correct apphash
agreed in principle, just in practice we got bitten somewhat, so can we make it simpler or more forgiving of mistakes?
just remembered an update
in the near future we'll want to coordinate a local configuration change for validators to update so that we have faster block times. this can be done asynchronously
i think we can get block times < 2 seconds, just gotta confirm w Polaris how fast they are looking for
it will result in consuming more storage tho (ie. producing 3x more blocks)
not sure what will enact this--maybe it's already done--but shielded sync will only take ~12s to 20s thanks to compression
if it's an older spending key, it will be on the longer side to sync
new users will be synced ++fast
Good thing is that storage usage in Namada is relatively low compared with other chains, let's see having 2s block times